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1.  Introduction 


1.1  Technology  Assessment 

Unmanned  ground  vehicle  tactical  behavior  is  a  continuing  area  of  technology  research  and 
development.  As  the  technology  progresses,  it  is  necessary  to  assess  the  technology  in  terms  of 
the  capability  it  provides  to  the  Soldier.  Data  from  assessments  also  conveys  a  state  of  the 
technology  that  the  research  community  can  use  to  track  the  progression  of  the  technology  over 
time. 

As  the  ability  for  unmanned  ground  vehicles  to  perform  complex  tactical  behaviors  approaches, 
there  is  a  corresponding  need  to  develop  the  methods  and  infrastructure  required  to  assess  these 
technologies  in  a  relevant  environment.  The  U.S.  Anny  Research  Laboratory  (ARL)  is  working 
towards  establishing  means  by  which  to  assess  unmanned  technology,  specifically  in  the  area  of 
autonomous  tactical  behaviors. 

1.2  Background 

The  unmanned  ground  vehicle  used  in  this  tactical  behaviors  assessment  was  the  experimental 
unmanned  vehicle  (XUV),  described  in  other  reports. 1  Each  XUV  is  approximately  1588  kg 
(3500  lb),  has  four-wheel  drive,  and  four-wheel  steering.  It  is  equipped  with  a  suite  of  advanced 
technology  in  perception  and  intelligent  control  and  an  operator  control  unit  (OCU)  interface. 
Prior  to  2007,  this  system  was  capable  of  traversing  terrain  in  a  relevant  environment  wherein  the 
XUV  followed,  within  a  specified  path  tolerance,  a  route  plan  generated  from  course  a  priori  data 
(deliberative  layer  planning).  As  designed,  the  exhibited  behavior  included  reliance  on 
autonomous  mobility  sensors  and  underlying  algorithms  to  detect,  classify,  and  react  to  local 
terrain  features  in  an  attempt  to  follow  the  prescribed  path  (perceptive  layer  planning).  The 
resolution  and  accuracy  of  the  a  priori  data  used  to  generate  the  route  path  was  often  insufficient 
to  enable  the  XUV  to  navigate  without  requiring  it  to  negotiate  scenarios,  such  as  cul-de-sacs, 
from  which  the  XUV  could  not  autonomously  extricate  itself.  The  motivation  for  the  recent 
work  is  to  enable  the  XUV  to  use  the  best  infonnation  available  from  multiple  sources  and  to 
bridge  the  deliberative  and  perceptive-level  planning  such  that  the  unmanned  ground  vehicle  has 
the  ability  to  use  terrain  features  to  tactical  advantage  including  finding  a  suitable  position  from 
which  to  employ  onboard  reconnaissance  surveillance  target  acquisition  (RSTA)  sensors  for 
observing  a  named  area  of  interest  and  planning  its  way  out  of  untraversable  situations  and 
avoiding  entering  into  those  situations.  The  Robotics  Program  Office  of  ARL  and  General 
Dynamics  Robotics  Systems  (GDRS)  has  engaged  in  exploratory  assessments  of  technologies 


1  Camden,  R.;  Bodt,  B.;  Schipani,  S.;  Bornstein,  J.;  Runyon,  T.;  French,  F.;  Shoemaker,  C.;  Jacoff,  A.;  Lytle,  A.  Autonomous 
Mobility  Technology  Assessment  Final  Report',  ARL-TR-347 1 ;  U.S.  Army  Research  Laboratory:  Aberdeen  Proving  Ground, 
MD,  2005. 
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that  support  these  motivations.  2,3  These  exploratory  assessments  have  provided  opportunities  to 
frame  scenarios,  protocol,  infrastructure,  and  metrics  for  continued  technology  assessment  while 
providing  current  data  feedback  for  the  architecture  developers. 

1.3  Purpose  of  This  Report 

The  purpose  of  this  report  is  to  document  the  results  of  an  unmanned  system  tactical  behaviors 
assessment  conducted  by  ARL  and  GDRS  on  4-14  February  2008.  The  purpose  of  the 
assessment  was  to  examine  the  ability  to  use  sensed  information  to  locally  orient  the  platform  in 
order  to  obtain  line  of  sight  for  an  onboard  RSTA  system  to  scan  a  sufficient  portion  of  a  named 
area  of  interest  (NAI);  and,  the  impact  of  advances  in  deliberative  layer  planning  technologies  to 
enhance  autonomous  mobility  in  a  relevant  environment.  The  first  purpose  is  addressed  in  the 
assessment  of  observation  post  finding  and  use  of  RSTA  in  section  2.  The  second  purpose  is 
addressed  in  the  discussion  of  the  interplay  of  infonnation  planning  at  multiple  levels  in  section 
3.  A  summary  and  references  are  provided  in  sections  4  and  5. 


2.  Tactical  Behaviors  Using  Observation  Posts  and  RSTA 


2.1  Background 

Observation  posts  (OP),  sometimes  called  observation  points,  are  used  to  conduct  reconnaissance 
and  surveillance  tasks,  which  are  part  of  the  RSTA  function.  OPs  are  locations  from  which 
Soldiers  can  observe  enemy  locations  or  movements  as  well  as  locate  potential  targets.  There  are 
many  aspects  to  finding  and  occupying  a  good  OP,  as  discussed  in  various  Anny  field  manuals 
(e.g.,  FM  3-20.98,  Reconnaissance  Platoon 4).  Two  important  aspects  of  a  good  OP  are  (1)  being 
able  to  see  what  you  want  to  see  and  (2)  to  not  be  seen  by  the  enemy. 

For  the  purposes  of  exploring  tactical  behaviors  for  unmanned  ground  vehicles,  we  used  the 
example  of  autonomously  finding  and  occupying  an  OP.  At  the  OP,  the  RSTA  system  on  the 
XUV  would,  first,  automatically  take  a  mosaic  (i.e.,  stitched  photograph)  of  the  previously 
identified  NAI.  The  mosaic  is  then  sent  to  an  operator  via  the  Soldier  machine  interface  (SMI) 
within  the  OCU  high-mobility,  multipurpose,  wheeled  vehicle  (HMMWV)  located  distant  from 
the  autonomous  XUV.  It  is  important  to  note  that  currently,  the  identification  of  a  good  OP  is 
based  solely  on  the  amount  of  visibility  to  the  area  of  interest.  The  selection  of  an  OP  which 


Hill,  S.  G.;  Bodt,  B.  A  Field  Experiment  of  Autonomous  Mobility:  Operator  Workload  For  One  and  Two  Robots. 
Proceedings  of  the  2007  ACM/IEEE  Conference  on  Human-Robot  Interaction  (HRI’07),  169-176,  2007. 
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cannot  be  seen  by  the  enemy  will  be  addressed  as  the  autonomous  tactical  behavior  capability 
evolves. 

2.2  Previous  XUV  OP  Finding  and  RSTA  Operations 

When  the  capability  to  perform  OP  finding  and  RSTA  operations  autonomously  by  the  XUV  was 
in  the  concept  phase,  a  pilot  study  for  OP/RSTA  operations  was  conducted  from  17-20  April 
2006  at  Fort  Indiantown  Gap,  tactical  maneuver  area  Bravo.  A  factorial  design  with  four 
replicate  runs  was  planned  using  noncommissioned  officers  from  the  U.S.  Anny  Unit  of  Action 
Maneuver  Battle  Lab  at  Fort  Knox,  KY,  as  operators.  The  portion  of  the  pilot  study  relating  to 
OP/RSTA  activities  was  primarily  to  demonstrate  the  capabilities  in  a  field  environment.  An 
outline  of  the  2006  pilot  study  is  given  in  table  1 . 

Table  1.  The  2006  pilot  study  objectives. 

_ Principle  Factors _ 

•  Operator  configurations:  one  operator/two  robots,  two  operators/two  robots 

•  Observation  point  (OP3,  OP5) _ 

•  Display  (screen,  tablet) 

_ Main  Questions  Addressed _ 

•  Assess  span  of  control  from  one  operator  to  two  overseeing  two  robots 

•  Assess  scalability  of  display  (vehicle-mounted  18-in  screen  vs.  10-in  portable  tablet) 

•  Assess  autonomous  mobility  changes  in  terms  of  speeds  and  interventions  since  TRL6 

•  Demonstrate  analysis  of  OP  location  and  mobility  planner  when  occupying  OP 

•  Demonstrate  live  RSTA 


Twenty-four  XUV  runs  were  conducted  during  which  the  operator  controlled  one  or  two  XUVs, 
using  either  the  HMMWV  OCU  or  a  tablet  OCU.  The  XUV  moved  on  one  of  two  routes  to  an 
OP.  Enroute  to  the  OP,  the  XUV  encountered  preplanned,  simulated  targets  at  designated 
locations  on  the  route.  The  operator  was  required  to  assess  the  target  using  the  RSTA  interface 
on  the  OCU.  On  arrival  at  the  OP,  the  plan  included  the  requirement  for  the  XUV  to  scan  the  OP 

and  find  a  suitable  location  providing  visibility  to  the  NAI.  The  observations  resulting  from  this 
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pilot  study  are  in  table  2.  The  2006  pilot  study  is  documented  further  in  Hill  and  Bodt. 

Following  the  pilot  study,  research  was  continued  to  improve  the  OP  planning  capability  and  the 
high-maneuverability  planner  (HMP)  for  small,  precise  XUV  movements.  Work  also  continued 
on  a  new  stabilized  RSTA  system  which  would  provide  vastly  increased  capabilities  over  the 
RSTA  used  in  the  2006  pilot  study. 
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Table  2.  The  2006  pilot  study  observations. 


Operator  Performance  Observations 

•  Monitoring  role  during  autonomous  OP  finding  missions 

•  One  operator  could  manage  two  robots  (depending  on  mission  specifics) 

•  Workload  increased  in  two  robot  missions  (over  one  robot) 

•  Communications  network  played  a  critical  role  in  performance 

•  Critical  information  elements:  communications  network  status,  robot  status,  and  RSTA 
camera  icon 

Human  Factors  Engineering  Observations 

•  Screen  and  tablet  both  usable  by  Soldiers 

•  Specific  suggestions  made  by  Soldiers — image  lists,  teleop  control  for  tablet,  tying  camera 
icon  to  image,  etc. 

Training  Issues  Observations 

•  Understand  latency  issues 

•  Understand  bandwidth  issues 

•  Understand  robot  behavior 

Future  Considerations 

•  Mission  complexity  (define,  measure,  manipulate) 

•  Collaboration  (e.g.,  sharing  robots  among  operators) 

•  Add  and  refine  operator  measures 

2.3  The  2008  OP  and  RSTA  Tactical  Behavior  Assessment  Approach 

The  2008  assessment  was  planned  as  a  follow-up  to  the  2006  pilot  study  because  of  several  key 
technology  upgrades: 

•  Two  OP  finder  algorithms  had  been  further  developed  and  integrated  with  a  more  capable 
HMP  for  precise  relocations  at  the  OP. 

•  A  stabilized,  multiple  field  of  view  (FOV)  RSTA  system  had  been  completed  and  deemed 
ready  for  use. 

The  2008  assessment  activity  included  a  number  of  XUV  runs  that  comprised  a  short,  preplanned 
mission,  consisting  of  a  start  point,  no  more  than  one  waypoint,  and  an  OP,  with  an  automatic 
RSTA  of  a  NAI.  At  the  OP,  the  OP  finder  algorithms  used  sensed  data  from  a  scan  performed 
with  the  onboard  laser  detection  and  ranging  (LADAR)  sensor  in  order  to  identify  locations  from 
which  the  RSTA  camera  would  have  a  large  percentage  (defined  for  each  run)  of  the  NAI 
visible.  The  HMP  planned  paths  for  the  XUV  to  move  to  the  identified  OP.  This  was  a 
successive  operation  in  which  an  acceptable  OP  would  be  identified  automatically,  the  XUV 
would  move  to  that  location;  then  a  new  sweep  would  either  confirm  that  this  was  a  good  OP,  or 
that  this  was  not  a  good  OP  (based  on  new  information  from  that  point).  If  the  location  was  not  a 
good  OP,  the  OP  finder  algorithms  and  HMP  would  repeat  the  process.  After  successive  moves, 
either  a  good  OP  would  be  identified  and  occupied,  or  no  good  OP  was  found,  or  the  planner  was 
unable  to  move  successfully  to  the  identified  good  OP.  All  this  activity  was  automatic;  there  was 
no  operator  input  to  the  OP  finder  or  HMP.  The  XUV  with  RSTA  system  is  shown  in  figure  1. 
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Figure  1.  XUV  with  RSTA  system. 


Once  the  XUV  stopped  moving  (in  either  a  good  or  a  not  good  OP  location),  an  automatic 
(preplanned)  RSTA  was  taken.  Each  algorithm  reported  the  success  or  failure  to  achieve  a  good 
OP.  A  good  OP  is  defined  as  a  location  with  visibility  to  the  NAI  exceeding  a  threshold  value 
(usually  70%  or  90%)  considering  all  obstacles  within  the  specified  range  of  the  LADAR  (either 
20  or  40  m  for  this  assessment).  The  operator  would  look  at  the  RSTA  image  on  the  SMI, 
identify  targets,  and  take  additional  RSTA  images  as  desired  to  clarify  his  assessment  of  the 
visibility  to  the  NAI  and  the  identification  of  targets.  This  completed  the  mission  run.  Data 
collected  included  the  SMI  log,  all  RSTA  images,  RSTA  metadata  in  extensible  markup 
language  (XML)  files,  the  mission  plan,  and  a  screenshot  from  the  end  of  the  run.  Activities 
throughout  each  run  were  manually  collected  by  an  observer.  Each  run  lasted  on  the  order  of 
10  min. 

2.4  OP  Courses  Used  in  the  2008  Assessment 

Four  OP  courses  were  selected  to  provide  a  variety  of  challenges  in  the  way  of  near-field 
obstacles,  distance  to  OP,  differences  in  elevation,  and  availability  of  a  priori  feature  data.  Each 
course  consisted  of  a  short  XUV  move  to  an  OP  that  overlooked  a  NAI.  The  NAI  was  populated 
with  recognizable  features  such  as  silhouettes  evenly  spaced  along  a  horizontal  line,  road 
intersections,  a  portable  toilet,  or  other  available  recognizable  features. 

To  provide  small  variations  in  the  OP  locations,  several  closely  spaced  OPs  were  used  at  each 
site,  normally  within  10  m  of  the  nearest  OP.  The  notion  was  to  determine  sensitivity  to  original 
OP  location.  The  four  courses  were  (1)  an  OP  at  the  crest  of  a  small  hill  overlooking  a  roadway 
at  200  m  (figure  2),  (2)  an  OP  behind  a  row  of  trees  in  a  low-lying  marshy  area  at  100  m 
(figure  3),  (3)  an  OP  at  the  intersection  of  two  trails  looking  up  at  a  road  and  assembly  area 
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Figure  2.  NA1  the  “Hill”  had  a  road  in  front  of  a  tree  line  at  250  m. 


Figure  3.  NA1  the  “Swamp”  was  behind  a  tree  line  with  a  priori  data. 

900-1400  m  away  (figure  4),  and  (4)  an  OP  among  bushes  and  trees  overlooking  a  building  and 
road  1000  m  away  (figure  5). 

Silhouettes  used  as  targets  in  the  NAI  were  green  plywood  with  painted  white  heads  and  white 
numbers  (figure  6).  The  objective  was  to  ensure  that  the  targets  were  readily  visible  to  the 
operator,  if  the  targets  were  within  the  operator’s  FOV  and  not  obscured  behind  trees  or  other 
obstacles.  The  detection  of  the  targets  was  not  intended  to  challenge  the  ability  of  the  operator  to 
see  and  report,  if  indeed  the  targets  were  visible  within  the  RSTA  image. 
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Figure  4.  NA1  C4  had  a  road  below  a  ridge  line  at  1—1.4  km. 


Figure  5.  NA1  the  “Bam”  included  the  ARL  building  and  road  at  1.0  km. 

2.5  Experimental  Design 

The  original  notion  was  to  run  four  replicate  runs  for  each  algorithm  against  a  specific  NAI.  The 
original  OP  location  for  each  of  the  four  runs  would  be  altered  by  10  m  or  so.  If  time  permitted, 
an  additional  four  runs  for  each  algorithm  would  be  done.  The  objectives  for  the  experiment  are 
presented  in  table  3.  For  numerous  reasons,  the  original  experimental  plan  could  not  be 
followed.  The  scope  of  the  experiment  was  widened  to  explore  several  new  variables,  including 
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levels  of  the  visibility  threshold  value  needed  for  achievement  of  a  good  OP,  and  the  scan  size, 
which  is  the  area  in  which  the  OP  finder  looks  for  a  new  OP.  It  was  decided  that  two  levels  of 
visibility  threshold  would  be  used  (70%  and  90%).  A  fourth  OP-NAI  combination  (the  “Bam”) 
was  added  to  expand  the  variety  of  OP  locations  used.  At  each  location,  we  attempted  to  run  a 
balanced  number  of  runs  but  were  precluded  by  weather  and  technical  challenges.  Seventy-two 
runs  were  completed  with  data  collection. 

Table  3.  The  2006  experimental  objectives. 


Principal  Factors 

•  OP  finder  -  two  independent  technical  approaches 

•  OP  characteristics  -  range  to  NAI  and  size  of  NAI 

Threshold  -  %  of  coverage  of  the  NAI  required  to  achieve  a  “good  OP”  (70%,  90%) 

•  Scan  size  -  the  area  in  which  the  OP  finder  searched  for  a  “good  OP”  (20  nf ,  40  nf) 

•  End  point  tolerance  -  distance  from  the  new  OP  that  HMP  was  required  to  achieve 

Main  Questions  Addressed 

•  How  well  can  the  OP  finder  find  a  location  near  the  OP  that  yields  good  intervisibility  to  the  NAI  taking 
into  account  only  locally  sensed  obstacles? 

•  Each  OP  finder  reported  if  threshold  intervisibilty  requirement  was  met  (Y/N) 

•  Intervisibilty  (coverage)  was  estimated  from  the  RSTA  scans  taken  at  new  OP 

•  How  close  to  the  new  OP  does  HMP  need  to  come? 

Other  Aspects  Assessed 

•  RSTA  operations 

2.6  OP  Finder  Operation 

Two  OP  finders  were  used  in  the  experiment,  OP  finders  “A”  and  “B.”  The  two  OP  finders  were 
independent  of  each  other;  only  one  OP  finder  was  used  on  each  ran.  Both  worked 
operationally  the  same.  Their  goal  was  to  find  a  location  near  the  OP  which  provided  a  measure 
of  visibility  to  the  NAI,  which  exceeded  a  threshold  value.  When  the  XUV  came  within  the 
30-rn  waypoint  tolerance  of  the  OP,  it  automatically  stopped  and  perfonned  a  wide-area  LADAR 
scan.  At  that  point  the  one  of  the  OP  finders  was  invoked  and  searched  for  one  or  more  locations 
within  an  area  defined  by  the  scan  size,  which  exceeded  the  visibility  threshold.  If  at  least  one 
new  good  OP  was  found,  the  list  of  good  OPs  was  passed  to  the  HMP,  which  selected  the  new 
OP  with  the  least  mobility  cost.  If  the  current  XUV  location  was  one  of  those  good  OPs,  the 
autonomous  mobility  portion  of  the  scenario  was  completed  and  the  RSTA  scan  of  the  NAI  was 
automatically  invoked.  If  the  current  location  of  the  XUV  was  not  a  good  OP,  the  HMP  then 
moved  the  XUV  to  the  new  OP  location  (actually  within  x  meters  of  the  new  OP,  x  being  a 
variable  set  to  3  m).  The  process  was  then  repeated  beginning  with  a  new  wide-area  LADAR 
scan.  If,  at  any  time,  the  OP  finder  could  not  find  a  good  OP  within  an  area  defined  by  the  scan 
size,  the  autonomous  mobility  portion  of  the  scenario  was  completed  and  the  RSTA  scan  of  the 
NAI  was  automatically  invoked.  Figures  7-9  illustrate  the  OP  finder  process. 
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Figure  6.  Silhouettes. 


Figure  7.  OP  finder  process  (1  of  3). 

OP  finder  A  considered  both  the  information  from  the  LADAR  scan  as  well  as  any  a  priori  data 
on  obstacles  between  its  location  and  the  NAI.  OP  finder  B  considered  only  the  information 
from  the  LADAR  scan. 

2.7  The  2008  Assessment  Operations 

The  XUV  was  positioned  at  the  start  point,  usually  about  50-60  m  from  the  OP.  A  plan  was 
generated  which  took  the  XUV  directly  to  the  OP  via  one  or  more  waypoints.  At  the  OP,  the 
plan  commanded  a  RSTA  scan  of  the  NAI.  The  run  configuration  was  checked  (scan  size,  OP 
finder,  etc.)  and  the  plan  was  executed  from  the  SMI  in  the  HMMWV  OCU.  The  XUV 
proceeded  toward  the  OP  until  it  came  within  the  30  m  waypoint  tolerance  of  the  OP.  At  that 
point,  the  XUV  halted  and  did  a  wide  LADAR  scan  of  area  in  front  of  the  XUV.  The  OP  finder 
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used  the  LADAR  returns  to  find  one  or  more  locations  within  an  area  defined  by  the  scan  size, 
which  exceeded  the  threshold.  For  20  m,  the  planner  algorithm  would  identify  good  OPs  using 
only  the  closest  20  m  of  the  LADAR  scan.  A  list  of  OPs  that  met  the  threshold  (e.g.,  70%) 
would  be  made  and  the  HMP  would  plan  to  one  of  the  good  OPs  (not  necessarily  the  best  OP,  it 
just  had  to  meet  the  threshold).  For  the  40  m,  the  planner  would  identify  good  OPs  using  40  m 
of  the  LADAR  scan.  A  list  of  OPs  that  met  the  threshold  would  be  made.  If  one  of  the  good 
OPs  was  within  20  m,  the  HMP  would  choose  an  OP  within  20  m  and  move  to  it.  If  there  was  no 
good  OP  within  20  m,  but  there  was  a  good  OP  within  40  m,  the  HMP  would  move  towards  the 
perimeter  of  the  original  scan  area  and  have  a  moving  20  m  distance  in  which  it  could  identify 
and  plan  to  a  good  OP  that  satisfied  the  threshold.  Again,  it  was  not  necessarily  the  best  OP,  just 
one  meeting  the  criterion.  Based  on  which  direction  the  HMP  moved  towards  the  edge  of  the 
20  m,  it  would  pick  an  OP  to  which  it  could  plan.  The  area  size  that  the  HMP  moves  in  can  be 
changed,  but  this  requires  modification  to  the  code.  Therefore,  for  this  assessment  it  was  a  given 
parameter.  For  the  HMP,  there  is  a  trade-off  on  distance  and  amount  of  time  it  takes  to  make  the 
plan. 

2.8  Data  Collection 

Data  collected  included  the  SMI  log,  all  RSTA  images,  RSTA  metadata  in  XML  files,  the 
mission  plan,  and  a  screenshot  from  the  end  of  the  run.  Activities  throughout  each  run  were 
manually  collected  by  an  observer. 

2.8.1  SMI  Log  Sample 

A  small  sample  from  the  SMI  log  is  given  in  figure  10.  The  SMI  log  contains  some  indications 
of  button  pushes  and  actions  from  the  data  that  is  used  by  the  SMI. 


00:10:36.78  si  XUV3  working  towards  wp  1 
00:10:58.81  si  XUV3  backing  up 
00:10:59.31  si  XUV3  done  backing  up 

00:11:22.79  si  Button  pressed  [RSTA]  ((select|view|show|display|look  at|change  to|switch  to) 
rsta[  display |  view])  =  selected 

00:11:28.85  si  Wca:  XUV3  Advisory,  Ready  to  Continue 
00:11:28.85  si  XUV3  state  change  Waiting 
00:11:29.37  si  selected  mosaic  03400001 
00:11:29.37  si  XUV3  recon  report 

00:11:29.37  si  Wca:  XUV3  Advisory,  Received  RECON  report 
00:11:34.78  si  Button  pressed  []  (zoom  in)  =  unselected 
00:11:56.44  si  Button  pressed  [Mosaic:  ]  (mosaic)  =  selected 


Figure  10.  An  example  from  an  SMI  log  collected  for  each  run. 
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2.8.2  Mosaic  Sample 


The  RSTA  images  were  primarily  mosaics,  which  are  a  series  of  images  stitched  together  to 
make  a  single  continuous  image.  The  mosaics  can  be  taken  using  different  FOVs.  An  example 
of  a  mosaic  with  targets  is  given  in  figure  1 1 . 


Figure  11.  Mosaic  ofNAI  from  OP  on  the  “Hill.” 

2.8.3  Mosaic  Metadata  Sample 

For  each  mosaic,  there  is  some  descriptive  data  about  the  each  image  that  is  stored  in  an  XML 
file  external  to  the  SMI  application  itself.  The  descriptive  data,  including  such  items  as  the  file 
name  and  field  of  view,  are  called  metadata.  An  example  of  the  mosaic  metadata  is  given  in 
figure  12. 


-  <SMI> 

-  <Recon  muid="0x3400001"  parent-'OxOOOOOOOO"  back="0x03400001"  camera="0" 
fov="20.1"  host="148. 33.195.21"  file="m_0x03400001.jpg" 

localPath="Missions\SWAMP\rsta\Mosaic0x0340000 1  .jpg"  ftpStatus="3"  left- ’0.20" 
right-' 0.67"  top="0.22"  bottom="6.13"  name="03400001"  activity="4"  complete="100" 
created-'  1202412120"  updated="4 167632"  active="0"> 

<utm  zone—' 18"  easting="361914.19"  northing="4478621.50"  elevation="- 196.66"  /> 
</Recon> 

</SMI> 


Figure  12.  An  example  of  RSTA  mosaic  metadata  collected  for  each  run. 

2.8.4  Screenshot  Sample 

Figure  13  shows  an  example  of  a  screen  shot  of  the  final  map  view  of  the  SMI  that  was  collected 
for  each  run. 
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Figure  13.  Screen  shot  of  SMI  following  a  mission  at  the  “Swamp”  OP. 

2.8.5  Plan  Description  Sample 

A  plan  description  for  each  run  was  stored  in  an  XML  file  external  to  the  SMI  application.  The 
plan  file  was  collected  for  each  run.  A  sample  of  the  plan  description  is  shown  in  figure  14. 


-  <SMI> 

<Plan  muid="0x3200047D"  name="plan  1"  status="3"  planError-'"  created-'  1202397400" 
updated- '1202397400">(ramp  XUV  (move-on-route  max-speed  4.40  (tolerance  30.00) 
(route  waypoints  (Z18N  4478721.0  361409.8  213.0  0x0) ) )  )</Plan> 

</SMI> 


Figure  14.  An  example  of  a  plan  description  collected  for  each  run. 


2.9  Data  Reduction 

After  the  assessment  was  completed,  the  data  collected  were  compiled  into  usable  forms.  These 
data  are  described  in  the  following  subsections. 

2.9.1  Run  Identifiers 

Each  run  was  given  an  identifying  number  and  was  characterized  by  several  independent  factors: 

•  OP  finder  algorithm  used  (A  or  B) 

•  OP  course  (one  of  the  four  courses) 

•  Threshold  (%  of  visibility  criterion,  usually  70%  or  90%,  with  a  few  60%  or  80%) 
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•  Scan  size  (20  or  40  m) 

•  Specific  OP  location  (several  at  each  course) 

2.9.2  Dependent  Measures 

Four  primary  dependent  measures  were  obtained  for  each  run.  The  first  was  a  “yes”  (Y)  or  “no” 
(N)  for  each  run  as  to  whether  a  good  OP  had  been  reported  by  the  OP  finder  software.  The 
second  measure  was  the  number  of  repositions  that  were  made  for  each  run,  i.e.,  the  number  of 
times  the  XUV  moved  to  a  new  OP  position.  The  third  was  the  number  of  targets  reported  by  the 
operator  at  the  time  of  the  first  automatic  RSTA  image  appearing.  Finally,  the  fourth  measure 
was  obtained  from  the  RSTA  images  after  the  assessment  was  completed;  this  resulted  in  the 
RSTA  picture  analysis  estimate  of  the  percentage  observed  of  the  NAI. 

2.9.3  RSTA  Picture  Analysis 

The  RSTA  picture  analysis  was  an  effort  to  obtain  an  independent  estimate  of  the  amount  of 
coverage  of  the  NAI  that  was  actually  observed  within  the  RSTA  photograph  (i.e.,  the  actual 
threshold).  Two  independent  raters  estimated  the  amount  of  coverage  of  the  NAI  (from  0%  to 
100%),  ratings  were  compared  and  a  final  coverage  estimate  (in  percent)  was  achieved.  Since 
the  LADAR  scan  for  OP  finding  only  used  the  scan  size  (i.e.,  20  or  40  m)  in  which  to  search,  the 
RSTA  picture  analysis  only  considered  occluded  views  in  the  20-  or  40-m  range  (whichever  is 
appropriate  for  each  run).  That  is,  if  there  were  trees  occluding  the  view  to  the  NAI  within  20  m 
(or  40  m)  of  the  XUV  (the  RSTA  picture  origin),  then  they  were  considered  as  blocking  the 
coverage  of  the  NAI.  However,  if  trees  were  located  in  the  distance  (further  than  the  20  or 
40  m),  those  trees  were  not  considered  as  blocking  the  coverage  of  the  NAI.  The  RSTA  picture 
analysis  yielded  an  estimate  of  coverage  for  each  run. 

2.9.4  Accepted  Runs 

Because  of  a  variety  of  extraneous  occurrences,  a  number  of  the  72  runs  were  not  suitable  for  use 
in  any  data  analysis.  These  reasons  included  heavy  snow  and  fog  obscuring  RSTA  pictures, 
emergency  stops  (E-stops),  software  crashes,  and  RSTA  failures.  Thus,  only  the  57  remaining 
runs  in  table  4  were  included  in  the  data  analysis. 

2.10  Human  Factor  Discussion 

A  number  of  human  factors  observations  were  made  during  the  technical  assessment  of  the  OP 
finders  and  HMP.  As  part  of  this  assessment,  the  RSTA  functions  were  used  and  observations 
made. 
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Table  4.  Accepted  OP  finder/RSTA  runs  (continued). 


Run 

Algorithm 

Site 

Threshold 

Tolerance 

Scan 

Size 

NAI 

No. 

Repositions 

Good 

OP 

No. 

Targets 

Coverage 

Estimate 

53 

A 

Swamp 

70 

3 

40 

A 

2 

Y 

NA 

80 

54 

A 

Swamp 

70 

3 

40 

A 

2 

Y 

NA 

40 

55 

A 

Swamp 

80 

3 

40 

A 

3 

Y 

NA 

80 

56 

A 

Swamp 

90 

3 

40 

A 

1 

Y 

NA 

50 

59 

A 

Hill 

70 

3 

40 

B  (right) 

2 

Y 

NA 

50 

61 

B 

Hill 

70 

3 

40 

B  (right) 

4 

N 

NA 

50 

64 

B 

Hill 

60 

3 

40 

B  (right) 

5 

N 

NA 

60 

65 

A 

Hill 

70 

3 

40 

B  (right) 

0 

Y 

NA 

30 

66 

A 

Hill 

80 

3 

40 

B  (right) 

1 

Y 

NA 

20 

67 

A 

Hill 

90 

3 

40 

B  (right) 

0 

Y 

NA 

20 

68 

A 

Hill 

90 

3 

40 

B  (right) 

4 

Y 

NA 

50 

69 

B 

Hill 

70 

3 

40 

B  (right) 

5 

Y 

NA 

30 

70 

B 

Hill 

70 

3 

40 

B  (right) 

6 

Y 

NA 

100 

80 

B 

B-OP 

70 

3 

40 

Bam 

0 

Y 

NA 

90 

82 

A 

B-OP 

70 

3 

40 

Bam 

0 

Y 

NA 

100 

83 

A 

B-OP 

90 

3 

40 

Bam 

0 

N 

NA 

80 

84 

A 

B-OP 

70 

3 

40 

Bam 

0 

N 

NA 

0 

85 

A 

B-OP 

90 

3 

40 

Bam 

0 

N 

NA 

50 

86 

B 

B-OP 

70 

3 

40 

Bam 

1 

Y 

NA 

100 

87 

B 

B-OP 

90 

3 

40 

Bam 

1 

Y 

NA 

70 

88 

B 

B-OP 

70 

3 

40 

Bam 

2 

Y 

NA 

60 

90 

A 

B-OP 

70 

3 

40 

Bam 

1 

Y 

0 

60 

As  discussed  earlier,  the  assessment  activity  included  a  number  of  runs  that  comprised  a  short, 
preplanned  mission,  consisting  of  a  start  point,  no  more  than  one  way  point,  and  an  OP  with  an 
automatic  RSTA  of  an  NAI.  This  mission  was  executed  by  the  XUV.  The  two  OP  finder 
algorithms  were  used  to  identify  locations  from  which  the  RSTA  camera  would  have  a  large 
percentage  (defined  for  each  run)  of  the  NAI  visible.  The  HMP  planned  paths  for  the  XUV  to 
move  to  the  identified  OP.  This  was  a  successive  operation  in  which  an  acceptable  OP  would  be 
identified  automatically,  the  XUV  would  move  to  that  location;  then  a  new  sweep  would  either 
confirm  that  this  was  a  good  OP  or  that  this  was  no  longer  a  good  OP  (based  on  new  information 
from  that  point).  If  no  longer  a  good  OP,  the  OP  finder  algorithms  and  HMP  would  try  to 
identify  and  move  to  a  better  location.  After  successive  moves,  either  a  good  OP  would  be 
identified  and  occupied  or  no  good  OP  was  found  or  the  planner  was  unable  to  move 
successfully  to  the  identified  good  OP.  All  this  activity  was  automatic;  there  was  no  operator 
input  to  the  OP  finder  or  HMP. 
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Once  the  XUV  stopped  moving  (in  either  a  good  or  a  not  good  OP  location),  an  automatic 
(preplanned)  RSTA  was  taken.  The  operator  would  look  at  the  RSTA  image  on  the  SMI, 
identify  targets,  and  take  additional  RSTA  images  as  desired.  This  then  completed  the  mission 
run  and  data  were  saved  for  later  analysis.  Each  run  lasted  on  the  order  of  10  min. 

The  operators  were  technical  assessment  team  members.  The  analysis  of  the  OP  finder  and  HMP 
are  addressed  separately.  These  observations  are  from  a  user/operator  perspective  and  are 
presented  in  two  major  parts:  (1)  observations  on  the  OP  finder  and  HMP  part  of  the  mission 
and  (2)  observations  about  using  the  RSTA  functions  and  resulting  images. 

2.10.1  OP  Finder  and  HMP  Human  Factor  Observations 

1 .  OP  finder  status  messages  to  the  operator  are  inadequate.  Currently,  when  the  XUV 
achieves  the  OP  given  in  the  mission  plan  (within  whatever  point  tolerance  is  set),  the 
XUV  immediately  starts  using  the  OP  finder  software.  This  is  indicated  on  the  status  bar 
on  the  SMI  by  showing  “sweeping  OP,”  indicating  that  the  LADAR  is  now  sweeping  to 
obtain  data  for  the  OP  finder  algorithms.  No  other  status  infonnation  on  the  OP  scanning 
process  is  sent  to  the  operator. 

2.  This  tactical  behavior  and  the  required  interplay  between  XUV  and  operator  are  not  well 
defined.  The  OP  finding  tactical  behavior  assessed  here  demonstrated  the  ability  to  execute 
scripted  behaviors  that  would  identify  a  location  meeting  a  visibility  threshold  and  then 
move  to  that  identified  location.  The  operator  was  not  involved  in  these  scripted  behaviors, 
other  than  to  make  an  initial  identification  of  a  possible  observation  point.  Now  that  this 
ability  has  been  demonstrated,  future  tactical  behavior  implementation  should  be  defined 
thoughtfully  to  include  the  potential  role  of  the  operator,  the  operational  requirements  of 
the  Soldier,  and  the  expertise  that  the  Soldier  could  contribute  to  achieving  the  goals  of  the 
tactical  behavior. 

3.  Software  developers  remained  and  were  required  to  be  in-the-loop  during  the  technology 
assessment.  Currently  several  parameters  were  set  for  each  run  by  the  software  developers. 
The  question  becomes  if  these  parameters  should  be  adjustable  for  operators  and  what  the 
appropriate  range  of  the  parameters  should  be.  Additional  work  needs  to  be  done  on 
defining  how  the  OP  tactical  behavior  will  work  and  what  options  will  be  available  to  the 
operator.  For  near-term  technical  assessments,  the  operator  should  be  able  to  set  those 
parameters  for  each  run  and  receive  the  infonnation  on  good/not  good  OP  location  and 
repositioning.  All  this  data  should  be  included  within  the  SMI  log. 

4.  Status  messages  are  ambiguous  or  incomplete.  There  are  a  number  of  operator  messages 
that  can  be  displayed,  some  requiring  intervention  and  others  providing  status  infonnation 
only.  Initially,  these  messages  were  aimed  toward  mobility — to  explain  why  the  XUV 
wasn’t  moving.  As  other  messaging  is  implemented,  for  example  sweeping  OP  and  other 
messages  associated  with  OP  tactical  and  RSTA  functions,  an  individual  message  could 
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possibly  have  some  ambiguous  meanings.  For  example,  the  current  status  “pause” 
indicates  a  pause  in  mobility. 

However,  as  other  functions  are  executed  (like  RSTA)  could  “pause”  also  be  interpreted  as  a 
pause  in  the  execution  of  another  task?  Stated  another  way,  are  there  any  messages  that  are 
possibly  misinterpreted  or  ambiguous  as  the  ability  of  the  operator  to  control  additional  functions 
increases?  As  new  functions  and  capabilities  increase,  it  would  be  useful  to  revisit  the  entire  set 
of  messages  to  ensure  that  status  and  intervention  messages  are  clear  and  useful  to  the  operator. 

2.10.2  RSTA  Human  Factor  Observations 

1 .  RSTA  “blue  lines”  did  not  convey  the  infonnation  which  was  intended.  Blue  lines, 
forming  an  angle,  are  placed  on  the  map  view  when  a  RSTA  has  been  taken.  This  gives  an 
indication  of  the  angular  coverage  (i.e.,  the  reconnaissance  straight  line)  across  which  a 
RSTA  mosaic  has  been  taken.  Multiple  blue  lines  will  be  displayed  and  overlay  each 
other;  it  is  difficult  to  distinguish  among  them  and  to  make  “pairs”  of  the  lines.  The  blue 
lines  do  not  extend  to  the  NAI  to  see  if  the  reported  RSTA  coverage  is  the  same  as  what 
was  intended.  Each  pair  of  blue  lines  is  not  associated  with  a  particular  mosaic,  through 
labeling  or  other  means,  so  it  is  difficult  to  check  the  map  view  vs.  the  actual  image. 
Therefore,  the  blue  lines  are  not  as  useful  as  they  could  be. 

2.  RSTA  image  file  names  were  not  unique  and  had  no  meaning  to  the  operator.  Currently, 
the  image  file  names  are  assigned  by  the  SMI  to  each  individual  image.  The  current  file 
names  are  not  meaningful  to  the  operator,  with  the  exception  of  the  sequence  numbering  at 
the  end.  So,  for  example,  a  mosaic  image  could  be  called  Mosaic0x03400014  and  the  next 
in  sequence  is  called  Mosaic0x03400015.  Snapshots  and  chips  are  named  in  a  similar  way. 
Some  mosaics  also  have  a  letter  at  the  end,  e.g.,  Mosaic0x03400001B.  Operators  can 
currently  change  the  mosaic  name  on  the  RSTA  screen,  but  it  does  not  change  the  file 
name  under  which  the  image  is  stored.  We  also  observed  that  the  same  file  names  are  used 
for  different  images,  when  RSTA  images  are  taken  on  different  days,  times,  and  missions 
over  a  number  of  runs. 

3.  Status  of  RSTA  operation  and  images  not  readily  apparent  to  the  operator.  In  the  recent 
technical  assessment,  the  operator  would  infer  a  RSTA  picture  was  taken  by  the  “pause” 
status  during  the  OP  tactical  behavior.  A  camera  icon  appears  and  a  RSTA  mosaic 
rectangle  shows  on  the  RSTA  screen  and  gives  a  percentage  complete  indication  for 
downloading  the  image  from  the  XUV  to  the  SMI.  The  operator  would  then  open  the 
image  for  display  on  the  SMI. 

Some  RSTA  scans  that  required  a  mosaic  would  stop  before  the  mosaic  had  been  completed.  No 
indication  of  the  premature  stop  was  given  to  the  operator  nor  indicated  on  the  mosaic.  No  other 
information  about  the  premature  stop  was  given.  Also,  it  would  be  helpful  to  have  infonnation 
on  the  status  of  the  RSTA  operation.  Currently,  the  taking  of  a  RSTA  scan  is  infened; 
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sometimes  transmission  of  images  is  affected  negatively  by  the  communications  network  and 
status  (picture  taken?  picture  available?  picture  complete?)  is  not  readily  available.  With 
additional  infonnation,  the  operator  might  choose  to  take  another  RSTA  scan  in  the  same  or 
different  location. 

4.  Mosaic  and  submosaics  processes  were  confusing  to  the  operator.  There  are  multiple 
FOVs  available,  ranging  from  1.3°  to  20°.  Each  mosaic  is  a  set  of  multiple  images  of  a 
particular  FOV  stitched  together  to  make  one  larger  image.  The  top  level  is  20°  FOV. 
Within  each  FOV,  the  operator  can  manually  zoom  in  to  different  levels  to  see  the  image. 

A  submosaic  is  when  a  smaller  area  within  the  original  mosaic  is  chosen,  by  drawing  a  box 
around  it,  and  a  series  of  images  are  stitched  together  to  make  an  image.  The  submosaic 
can  be  taken  using  the  same  or  a  different  FOV. 

Several  observations  were  made.  Currently,  you  can  take  a  submosaic  only  from  the  original 
mosaic,  i.e.,  you  cannot  identify  a  submosaic  on  a  zoomed  in  image.  This  then  requires  the 
operator  to  remember  what  kind  of  image  is  being  viewed  and  to  (possibly)  click  on  another 
image  or  to  unzoom  in  order  to  get  a  submosaic.  An  operator  should  be  able  to  execute  a 
function,  like  a  submosaic,  from  any  location  and  not  have  to  remember  a  current  image  state  or 
how  to  get  to  a  required  image  state. 

Another  observation  is  that  the  FOV  changes  automatically  to  the  next  lower  level  after  a  mosaic 
is  taken.  For  example,  if  an  automatic  RSTA  is  taken  at  20°  FOV,  the  FOV  button  is 
automatically  changed  to  the  10°  FOV  choice.  This  can  be  confusing  to  the  operator,  especially 
since  there  is  no  other  easily  accessible  data  that  provides  information  about  a  particular  image 
and  FOV  for  that  image. 

Finally,  the  box  used  to  choose  the  area  for  a  submosaic  can  be  drawn  outside  of  the  original 
mosaic  image.  It  could  be  misinterpreted  that  drawing  the  submosaic  box  outside  of  the  mosaic 
photo  could  capture  an  image  outside  the  original  mosaic  (it  can’t). 

5.  RSTA  mosaic  failed  on  occasion  because  of  memory  allocation  problems  and  failed  to 
infonn  the  operator  of  the  failure.  Currently  there  are  memory  limitations  within  the  SMI 
for  the  size  of  the  RSTA  images  that  can  be  taken.  The  few  times  that  the  limits  were 
exceeded,  the  RSTA  failed  by  just  stopping,  showing  0%  complete  and  hanging  up  at  that 
point.  No  additional  information  was  given  to  the  operator.  The  XUV  had  to  be  rekeyed. 
The  times  when  the  memory  limits  were  reached  seemed  to  be  related  to  taking  long  (i.e., 
wide)  scans  at  narrow  FOVs. 

Possible  alternatives  should  be  explored,  such  as  increasing  memory,  providing  guidance  to  the 
operator  on  allowable  images,  and  including  real-time  status  messaging  on  submosaic  limits. 
Also,  possible  ideas  expressed  by  a  RSTA  software  developer  include  “poor  man’s  stitching” 
where  the  mosaic  is  imprecisely  put  together,  trading  speed  with  precision  and  memory.  Another 
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idea  was  to  divide  the  single  mosaic  into  multiple  smaller  images — this  might  become  a  decision 
that  the  operator  could  make. 

6.  Manual  RSTA  is  very  difficult  on  the  RSTA  SMI.  Currently,  for  manual  RSTAs,  a  set  of 
boxes  attached  by  a  line  is  presented  on  the  RSTA  map  screen  when  manual  RSTA  is 
chosen.  These  boxes  are  very  difficult  to  manipulate  on  the  small  RSTA  map  screen,  in 
many  cases  being  almost  hidden  behind  the  XUV  icon.  The  manipulation  was  particularly 
difficult  when  the  NAI  was  a  longer  distance  away,  on  the  order  of  >1  km  away.  For  the 
view  we  had,  the  XUV  icon  always  had  to  stay  on  the  RSTA  screen,  which  then  required 
the  map  be  zoomed  out  to  a  scale  where  features  were  small.  The  boxes  were  difficult  to 
place  on  exact  locations  when  the  map  was  such  a  small  scale.  Even  if  the  XUV  did  not 
have  to  be  on  the  same  map,  you  might  want  the  XUV  and  the  NAI  displayed  together  to 
get  a  sense  of  what  you  were  investigating. 

2.11  General  Observations 

2.11.1  Weather  Effects 

On  a  number  of  runs,  rain  and  snow  clouded  the  lens  cover  of  the  RSTA  system  and  interfered 
with  the  quality  of  the  RSTA  picture  and  with  the  proper  creation  of  a  mosaic.  This  limited  the 
number  of  runs  in  which  meaningful  data  and  pictures  could  be  collected.  Examples  of  RSTA 
images  taken  during  rain  and  fog  are  shown  in  figures  15  and  16. 


Figure  15.  Fog  at  NAI. 


Figure  16.  Rain  and  fog  at  NAI. 
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2.11.2  XUV  Azimuth  at  OP 


On  several  occasions,  the  XUV  arrived  at  the  new  OP  on  an  azimuth  pointing  away  from  the 
NAI,  making  the  wide-area  LADAR  scan  ineffective  in  determining  the  suitability  of  the  new 
OPs.  This  yielded  false  OP  finder  algorithm  results  since  no  obstacle  could  be  seen  between  the 
XUV  and  the  NAI.  An  example  of  a  screen  shot  that  shows  the  XUV  (the  numbered  rectangle) 
pointing  away  (to  the  bottom  of  the  screen)  instead  of  towards  the  NAI  (the  orange  line)  is 
shown  in  figure  17. 


Figure  17.  XUV  at  OP  pointing  away  from  NAI. 

2.11.3  OP  Finder  Improves  the  Quality  of  the  Location  Selected  as  an  OP 

The  data  analysis  shows  that  the  OP  finder  algorithms  improve  the  quality  of  selection  of  an  OP 
location. 

2.11.3.1  Algorithm  Reported  Results.  There  were  57  runs  used  in  this  data  analysis.  Using  the 
algorithm-reported  results,  when  the  XUV  arrived  at  the  originally  designated  OP,  that  location 
was  a  good  OP  on  16  of  the  57  runs  (28%)  (figure  18).  The  initial  location  for  13  of  57  runs 
(23%)  was  not  a  good  OP,  and  the  OP  finder  could  not  find  an  alternate  OP  that  met  the 
threshold  requirements  for  visibility  to  the  OP.  The  remaining  28  runs  continued  on  with  the  OP 
finder  looking  for  an  acceptable  OP  location. 
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Figure  18.  Initial  decision  at  OP. 


When  OP  finder  was  invoked  and  repositioning  took  place,  an  additional  25  of  28  good  OPs 
(89%),  reported  by  the  algorithm  were  found  (figure  19).  Thus,  when  the  OP  finder  could  find 
an  acceptable  OP,  the  HMP  was  successful  in  moving  the  XUV  to  a  location  with  acceptable 
visibility  to  the  NAI. 


Final  Decision  With  Repositioning 

Algorithm  Reported 


Good  OP 


Figure  19.  Final  decision  with  repositioning. 
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Overall,  41  of  the  57  runs  (72%)  resulted  in  a  good  OP  as  reported  by  the  algorithms. 
Performance  by  individual  algorithms  is  shown  next. 

2.11 .3.2  Algorithm  A  Reported  Results.  Using  the  algorithm  A  reported  results  on  32  runs, 
when  the  XUV  arrived  at  the  originally  designated  OP,  that  location  was  a  good  OP  on  10  of  the 
32  runs  (31%)  (figure  20).  The  initial  location  for  10  of  the  32  runs  (31%)  was  not  a  good  OP, 
and  OP  finder  A  could  not  find  an  alternate  OP  that  met  the  threshold  requirements  for  visibility 
to  the  OP.  The  remaining  12  runs  continued  on  with  OP  finder  A  looking  for  an  acceptable  OP 
location. 


Initial  Decision  at  OP 

Algorithm  (A)  Reported 


Figure  20.  Initial  decision  at  OP  (algorithm  A). 

When  OP  finder  A  was  invoked  and  repositioning  took  place,  an  additional  12  of  the  12  good 
OPs  (100%),  reported  by  the  algorithm,  were  found  (figure  21).  Thus,  when  OP  finder  A  could 
find  an  acceptable  OP,  the  HMP  was  successful  in  moving  the  XUV  to  that  location  where  there 
was  acceptable  visibility  to  the  NAI. 

Overall,  22  of  the  32  runs  (69%)  resulted  in  a  good  OP  as  reported  by  algorithm  A. 

2.11 .3.3  Algorithm  B  Reported  Results.  Using  the  algorithm  B  reported  results,  when  the  XUV 
arrived  at  the  originally  designated  OP,  that  location  was  a  good  OP  for  six  of  the  25  runs  (24%) 
(figure  22).  The  initial  location  of  three  of  the  25  runs  (12%)  was  not  a  good  OP,  and  OP  finder 
B  could  not  find  an  alternate  OP  that  met  the  threshold  requirements  for  visibility  to  the  OP.  The 
remaining  16  runs  continued  on  with  OP  finder  B  looking  for  an  acceptable  OP  location. 
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Final  Decision  With  Repositioning 
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Figure  21.  Final  decision  with  repositioning  (algorithm  A). 
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Figure  22.  Initial  decision  at  OP  (algorithm  B). 

When  OP  finder  B  was  invoked  and  repositioning  took  place,  an  additional  13  of  16  good  OPs 
(81%),  reported  by  the  algorithm,  were  found  (figure  23).  Thus,  when  OP  finder  B  could  find  an 
acceptable  OP,  the  HMP  was  successful  in  moving  the  XUV  to  that  location  where  there  was 
acceptable  visibility  to  the  NAI. 
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Final  Decision  With  Repositioning 

Algorithm  (B)  Reported 


Good  OP 


Figure  23.  Final  decision  with  repositioning  (algorithm  B). 

Overall,  19  of  the  25  runs  (76%)  resulted  in  a  good  OP  as  reported  by  algorithm  B. 

2. 1 1 .3.4  RSTA  Picture  Analysis  Results.  The  RSTA  picture  analysis  somewhat  tempers  the 
results  reported  by  each  algorithm.  Using  the  same  57  runs,  the  RSTA  pictures  were  analyzed 
and  coverage  of  the  NAI  estimated.  Using  the  RSTA  picture  analysis  of  the  OP  locations,  when 
the  XUV  arrived  at  the  originally  designated  OP,  that  location  was  a  good  OP  for  eight  of  the  57 
runs  (14%)  (figure  24).  The  initial  location  for  21  of  the  57  runs  (37%)  was  not  a  good  OP,  and 
the  OP  finder  could  not  find  an  alternate  OP  that  met  the  threshold  requirements  for  visibility  to 
the  OP.  The  remaining  28  runs  continued  on  with  the  OP  finder  looking  for  an  acceptable  OP 
location. 

When  the  OP  finder  was  invoked  and  repositioning  took  place,  an  additional  13  of  28  good  OPs 
(46%),  analyzed  by  the  RSTA  pictures,  were  found  (figure  25).  Thus,  when  the  OP  finder  could 
find  an  acceptable  OP,  the  HMP  was  successful  in  moving  the  XUV  to  that  location  where  there 
was  acceptable  visibility  to  the  NAI. 
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Figure  25.  Final  decision  with  repositioning  (RSTA  picture  analysis). 


Overall,  20  of  the  57  runs  (37%)  resulted  in  a  good  OP  based  on  the  RSTA  pictures. 

2.11 .3.5  Algorithm  A  RSTA  Picture  Analysis  Results.  Using  the  RSTA  picture  analysis  results, 
when  the  XUV  arrived  at  the  originally  designated  OP,  that  location  was  a  good  OP  for  four  of 
the  32  runs  (13%)  (figure  26).  The  initial  location  for  16  of  the  32  runs  (50%)  was  not  a  good 
OP,  and  OP  finder  A  could  not  find  an  alternate  OP  that  met  the  threshold  requirements  for 
visibility  to  the  OP.  The  remaining  12  runs  continued  on  with  OP  finder  A  looking  for  an 
acceptable  OP  location. 
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Figure  26.  Initial  decision  at  OP  -  algorithm  A  (RSTA  picture  analysis). 


When  OP  finder  A  was  invoked  and  repositioning  took  place,  an  additional  three  of  12  good  OPs 
(25%),  based  on  analysis  of  the  RSTA  pictures,  were  found  (figure  27).  Thus,  when  OP  finder  A 
could  find  an  acceptable  OP,  the  HMP  was  successful  in  moving  the  XUV  to  that  location  where 
there  was  acceptable  visibility  to  the  NAI. 
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Figure  27.  Final  decision  with  repositioning  -  algorithm  A  (RSTA  picture  analysis). 
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Overall,  seven  of  the  32  runs  (22%)  resulted  in  a  good  OP  by  algorithm  A  based  on  the  RSTA 
picture  analysis. 

2.1 1.3.6  Algorithm  B  RSTA  Analysis  Results.  Using  the  RSTA  picture  analysis  results,  when 
the  XUV  arrived  at  the  originally  designated  OP,  that  location  was  a  good  OP  for  four  out  of  the 
25  runs  (16%)  (figure  28).  The  initial  location  of  five  out  of  the  25  runs  (20%)  was  not  a  good 
OP,  and  OP  finder  B  could  not  find  an  alternate  OP  that  met  the  threshold  requirements  for 
visibility  to  the  OP.  The  remaining  16  runs  continued  on  with  the  OP  finder  looking  for  an 
acceptable  OP  location. 
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Figure  28.  Initial  decision  at  OP  -  algorithm  B  (RSTA  picture  analysis). 

When  the  OP  finder  was  invoked  and  repositioning  took  place,  an  additional  10  of  16  good  OPs 
(63%),  based  on  analysis  of  the  RSTA  pictures,  were  found  (figure  29).  Thus,  when  OP  finder  B 
could  find  an  acceptable  OP,  the  HMP  was  successful  in  moving  the  XUV  to  that  location  where 
there  was  acceptable  visibility  to  the  NAI. 

Overall,  14  of  the  25  runs  (56%)  resulted  in  a  good  OP  by  algorithm  B  based  on  the  RSTA 
picture  analysis. 

2.11.4  Algorithm  Reporting  vs.  RSTA  Picture  Analysis 

The  assessment  of  visibility  to  the  NAI  made  by  both  algorithms  is  optimistic  compared  to 
RSTA  picture  analysis.  Based  on  all  runs,  algorithm  A’s  performance  drops  from  69% 
self-reported  good  OPs  to  22%  RSTA  picture  analysis  good  OPs.  Algorithm  B’s  performance 
drops  from  76%  self-reported  good  OPs  to  56%  RSTA  picture  analysis  good  OPs  (figure  30). 
This  indicates  that  the  reported  NAI  coverage  is  not  well  calibrated  to  the  actual  coverage, 
assuming  that  the  RSTA  picture  analysis  yields  more  accurate  coverage  estimates. 
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Figure  29.  Final  decision  with  repositioning  -  algorithm  B  (RSTA  picture  analysis). 
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Figure  30.  OP  finder  performance  across  all  57  runs. 

2.11.5  OP  Finder  Works 

In  general,  OPs  reported  as  good  OPs  had  better  coverage  than  those  that  were  not  good  OPs, 
both  when  the  good  OP  was  reported  by  the  algorithm  (algorithm  reported)  or  determined  on  the 
basis  of  the  RSTA  picture  analysis.  An  algorithm  reported  good  OP  (“Y”)  yielded  better 
coverage  (algorithm  A  =  52%,  algorithm  B  =  71%)  of  the  NAI,  as  estimated  by  the  RSTA 
picture  analysis,  than  an  algorithm  reported  “N”  (algorithm  A  =  3 1%,  algorithm  B  =  37%) 

(see  figure  31). 
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Figure  31.  RSTA  picture  analysis  mean  coverage. 

When  the  runs  from  the  Hill  OP  are  removed  from  the  data,  the  RSTA  picture  analysis  yields 
similar  results  between  algorithms,  based  primarily  on  the  low  RSTA  analysis  coverage  of 
algorithm  A  on  the  runs  at  the  Hill  OP  (figure  32). 
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Figure  32.  RSTA  picture  analysis  mean  coverage  (Hill  data  removed). 
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2.11.6  Scan  Size  Relevance 

When  repositioning  was  required  to  achieve  the  requested  coverage  threshold,  there  is  no 
compelling  evidence  that  scan  size  was  a  significant  factor.  Based  on  the  algorithm-reported 
results,  scan  size  of  40  m  may  achieve  better  results;  however  when  measured  against  the  RSTA 
picture  analysis,  the  results  trend  in  the  opposite  direction  and  are  inconclusive.  This  is  shown  in 
figure  33. 
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Figure  33.  OP  finder  performance  vs.  scan  size. 

When  further  examined,  based  on  individual  algorithms,  the  difference  between  20-  and  40-m 
scan  size  when  the  algorithm  reported  results,  was  primarily  due  to  algorithm  A’s  performance 
where  40-m  scan  size  significantly  improved  the  chances  of  finding  a  good  OP  (figure  34). 

2.11.7  OP  Location  Variance 

Finding  a  good  OP  may  be  dependent  on  the  “goodness”  of  the  original  OP  selection  input  by  the 
operator.  OPs  input  by  the  operator  actually  used  in  the  planned  runs  were  varied  slightly 
(±10  m)  around  the  original  OP.  There  were  several  instances  when  the  variation  of  the  OP 
location  seemed  to  the  data  collectors  and  operator  to  result  in  differing  levels  of  visibility 
achieved  by  the  OP  finder.  This  observation  is  not  supported  strongly  by  data,  but  the  robustness 
of  the  OP  finder  with  regard  to  original  OP  location  as  input  by  operator  should  be  explored  in 
future  assessments. 

2.11.8  Algorithm  Performance 

Algorithm  B  perfonned  better  than  algorithm  A  in  achieving  good  OPs  in  both  methods  of 
determining  a  good  OP  (for  Y  or  N  responses,  and  in  the  RSTA  picture  analysis)  (figure  35). 
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Figure  34.  OP  finder  performance  vs.  scan  size  vs.  algorithm. 
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Figure  35.  Difference  in  algorithm  performance. 
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2.11.9  Variable  Ranges 

Results  did  not  indicate  the  correct  ranges  of  values  for  threshold  and  scan  size.  End  point 
tolerance  was  not  varied  and  hence  not  evaluated. 

2.11.10  Elevation  Calculations 

Differences  in  elevation  calculations  between  the  RSTA  camera  on  the  XUV,  obtained  through 
the  XUV  navigation  system  and  the  elevation  of  the  NAI  obtained  from  a  priori  data,  may  have 
affected  the  quality  of  the  RSTA  picture  if  the  a  priori  data  was  significantly  different  from  the 
actual  and  the  NAI  was  close  to  the  OP. 

2.11.11  Silhouettes 

Silhouettes  with  white  heads  were  more  easily  seen  in  the  RSTA  pictures  than  silhouettes  with 
red,  yellow,  or  orange  heads. 

2.12  Recommendations  Resulting  From  the  OP  Finding/RSTA  Technical  Assessment 

2.12.1  General 

1.  Continue  improvements  of  both  OP  finder  algorithms.  Both  approaches  performed 
sufficiently  well  to  continue  their  advancement. 

2.  Calibrate  the  OP  finder  visibility  estimation  on  a  static,  well-defined  test  area  prior  to  next 
field  experiment. 

3.  When  stopping  at  a  new  OP  after  a  repositioning,  the  HMP  should  leave  the  XUV  pointing 
to  within  45°  of  the  center  of  the  NAI. 

4.  Generate  a  more  complete  OP  finder  definition  (see  appendix  A).  The  current  approaches 
are  initial  efforts  and  a  more  refined  definition  can  be  generated  based  partially  on  what  has 
been  learned  during  this  assessment. 

2.12.2  OP  Finder  and  HMP  Human  Factor  Recommendations 

1 .  In  the  near  term,  implement  appropriate  operator  status  messages  used  for  OP  finders  onto 
the  SMI.  Report  these  messages  (at  least  the  change  in  state  of  the  messages)  in  the  SMI 
log  for  further  analysis.  Whether  these  status  messages  need  to  be  displayed  in  the  long 
tenn,  as  the  behavior  becomes  more  sophisticated  and  reliable,  is  an  open  question  (see 
section  2.10.1). 

Define  OP  tactical  behavior  process  and  the  required  interplay  between  XUV  and  operator. 
Identify  which  parameters  should  be  available  to  operators  for  their  decision  and  use.  Implement 
the  choices  and  appropriate  messaging  into  the  SMI. 
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As  the  OP  tactical  behavior  is  further  developed,  determining  the  best  process  for  “OP  finding” 
will  include  active  consideration  of  the  part  that  the  operator  will  play  in  assessing  the  adequacy 
of  the  identified  OPs.  Certainly  there  are  circumstances  when  a  given  XUV  location  is  “good 
enough”  for  a  particular  purpose;  other  times  when  more  precision  is  required  by  the  operator.  It 
is  probable  that  an  interplay  between  the  OP  finder/HMP  and  the  operator  will  need  to  occur — 
the  XUV  will  find  a  location  that  satisfies  its  internal  OP  finder/HMP  software  criteria,  present 
that  to  the  operator  who  may,  in  turn,  find  that  location  “good  enough”  or  provide  revised 
parameters  for  another  try,  or  even  teleoperate.  The  possible  interactions  between  the  operator 
and  the  SW/HW  should  be  explored,  identified  and  a  good  process  defined  and  implemented  via 
the  SMI.  One  potential  process  to  define  the  OP  tactical  behavior  is  presented  in  appendix  A. 

2.  Remove  software  developers  from  being  in-the-loop  during  the  next  assessment.  For  near- 
term  technical  assessments,  the  operator  should  be  able  to  set  those  parameters  for  each  run 
and  receive  the  information  on  good/not  good  OP  location  and  repositioning.  All  this  data 
should  be  included  within  the  SMI  Log. 

3.  Revisit  all  status  messaging  to  ensure  status  messages  are  clearly  interpretable  by  the 
operator.  There  are  a  number  of  operator  messages  that  can  be  displayed,  some  requiring 
intervention  and  others  providing  status  infonnation  only.  Initially,  these  messages  were 
aimed  toward  mobility — to  explain  why  the  XUV  wasn’t  moving.  As  other  messaging  is 
implemented,  for  example,  sweeping  OP  and  other  messages  associated  with  OP  tactical 
and  RSTA  functions,  an  individual  message  could  possibly  have  some  ambiguous 
meanings.  For  example,  the  current  status  “pause”  indicates  a  pause  in  mobility.  However, 
as  other  functions  are  executed  (like  RSTA)  could  “pause”  also  be  interpreted  as  a  pause  in 
the  execution  of  another  task?  Stated  another  way,  are  there  any  messages  that  are  possibly 
misinterpreted  or  ambiguous  as  the  ability  of  the  operator  to  control  additional  functions 
increases?  As  new  functions  and  capabilities  increase,  it  would  be  useful  to  revisit  the 
entire  set  of  messages  to  ensure  that  status  and  intervention  messages  are  clear  and  useful 
to  the  operator. 

2.12.3  RSTA  Human  Factor  Recommendations 

1.  Revise  the  display  and  use  of  RSTA  “blue  lines.”  The  RSTA  blue  lines  (defined  in  section 
2. 10.2)  are  not  as  useful  as  they  could  be.  Recommend  examining  how  the  blue  lines  could 
be  improved  for  operator  use. 

2.  Make  image  file  names  meaningful  and  unique.  All  images  need  to  be  given  a  unique 
name  and  file  name  meaningful  to  the  operator,  such  as  a  date-time-group  or  vehicle  stamp. 

3.  Make  status  of  RSTA  operation  and  images  available  to  operator.  Include  easily  accessible 
and  meaningful  metadata  for  each  RSTA  image  within  the  SMI.  Explore  the  range  of 
issues  concerning  RSTA  image  management.  Metadata  that  is  easily  accessible  and  readily 
understandable  by  Soldiers  is  needed  for  RSTA  images  and  should  be  available  within  the 
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SMI.  The  images  should  also  be  able  to  be  easily  accessible,  categorized,  manipulated,  and 
compared.  Perhaps  time/date  stamps  should  be  superimposed  on  the  images  themselves  (as 
current  commercial  technology  does).  Labels  should  be  meaningful.  Applications  are 
currently  available  that  allow  keywords  and  other  data  to  be  associated  with  each  image 
and  provide  the  ability  to  sort  and  display  images. 

Whether  or  not  all  of  this  is  included  within  the  current  SMI  is  an  open  question.  However,  these 
kinds  of  “image  management”  issues  should  be  explored  if  RSTA  functions  are  to  be  integrated 
into  the  XUV  operator  tasks.  First,  operator  functions  required  for  image  and  reconnaissance 
management  should  be  identified.  Seeing  how  commercial  software  handles  these  required 
functions  is  another  useful  step.  Exploring  alternative  interface  ideas  and  integration  of  these 
ideas  with  other  XUV  functions  will  also  be  needed. 

4.  Revise  particular  FOV  and  submosaics  elements.  An  operator  should  be  able  to  execute  a 
function,  like  a  submosaic,  from  any  location  and  not  have  to  remember  a  current  image 
state  or  how  to  get  to  a  required  image  state. 

Do  not  decrement  the  FOV  automatically  after  taking  a  mosaic.  For  example,  if  an  automatic 
RSTA  is  taken  at  20°  FOV,  the  FOV  button  is  automatically  changed  to  the  10°  FOV  choice. 

This  can  be  confusing  to  the  operator,  especially  since  there  is  no  other  easily  accessible  data  that 
provides  infonnation  about  a  particular  image  and  FOV  for  that  image. 

Limit  the  designation  of  a  submosaic  to  an  area  within  the  original  mosaic.  The  box  used  to 
choose  the  area  for  a  submosaic  can  be  drawn  outside  of  the  original  mosaic  image.  It  could  be 
misinterpreted  that  drawing  the  submosaic  box  outside  of  the  mosaic  photo  could  capture  an 
image  outside  the  original  mosaic  (it  can’t). 

5.  Address  memory  limitations  for  RSTA  images  within  SMI.  Workarounds  should  be 
explored,  such  as  increasing  memory,  providing  guidance  to  the  operator  on  allowable 
images,  include  real-time  status  messaging  on  submosaic  limits.  Also  possible  ideas 
include  a  “poor  man’s  stitching”  where  the  mosaic  is  imprecisely  put  together,  trading 
speed  with  precision  and  memory.5  Another  idea  was  to  divide  the  single  mosaic  into 
multiple  smaller  images — this  might  become  a  decision  that  the  operator  could  make. 

6.  Make  manual  RSTA  operations  easier.  The  manual  RSTA  assignment  needs  to  be  made 
easier.  If  the  RSTA  map  view  is  primarily  for  manual  RSTAs,  perhaps  the  map  should  be 
larger  or  other  ways  should  be  provided  to  examine  manual  RSTAs  from  a  map  view.  This 
is  particularly  critical  when  the  RSTA  boxes  are  used  for  elevation  data,  as  they  are  for 
RSTA  and  OP  finding  tasks. 
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Pombo,  P.  General  Dynamics  Robotic  Systems,  Westminster,  MD.  Personal  communication,  1 1  February  2008. 
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2.12.4  Experimentation  Methodology  Recommendations 

1 .  Include  both  OP  tinders,  visibility  threshold,  scan  size  and  end  point  tolerance,  and  OP 
location  variance  as  variables  in  the  next  technology  assessment. 

2.  When  operating  in  rain  or  snow,  operations  SOP  should  include  cleaning  the  RSTA  lens 
cover. 

2.13  Conclusions  From  the  OP  Finding/RSTA  Technical  Assessment 

The  OP  tinders  and  the  HMP  combined  to  successfully  demonstrate  that  locally  sensed  terrain 
and  feature  data  can  be  successfully  utilized  to  find  and  move  the  XUV  to  an  OP  location  with 
improved  visibility  to  the  NAI.  Recommendations  for  improved  performance  and  follow-on 
assessments  were  made. 


3.  The  Interplay  of  Information  Planning  at  Multiple  Levels  for  UGV 
Mobility 


3.1  Background 

In  FY  2003,  ARL  and  GDRS  conducted,  with  testing  oversight  by  the  National  Institute  of 
Standards  and  Technology,  an  extensive  three-site  experiment  of  an  autonomous  navigation 
system  (ANS).1  The  ANS  relied  on  perceptive  level  planning  to  achieve  a  manually 
predetennined  route  of  way  points  in  rolling  desert,  rolling  vegetated  and  urban  terrain.  This 
system  was  capable  of  traversing  terrain  while  following  a  route  plan,  within  a  specified  path 
tolerance,  that  was  generated  from  course  a  priori  data  (deliberative  layer  planning).  In  this 
instantiation,  the  XUV  relied  on  autonomous  mobility  sensors  and  underlying  algorithms  to 
detect,  classify,  and  react  to  local  terrain  features  in  an  attempt  to  follow  the  prescribed  path 
(perceptive  layer  planning).  The  Future  Combat  Systems  used  this  study  as  part  of  the 
evaluation  that  led  to  a  Technology  Readiness  Level  6  designation  for  the  ANS.  Interim 
advances  in  the  Soldier  machine  interface  (SMI)  have  greatly  simplified  manual  route  planning, 
while  perception  algorithms  and  hardware  continued  to  mature.  More  recent  developments  in 
the  architecture  allow  for  deliberative  planning  in  a  move  toward  tactically  intelligent  behaviors. 

Higher-level  deliberative  planning  draws  on  the  objective  of  the  operation  and  the  global  map  of 
a  priori  information,  which  consists  of  elevation  and  terrain  feature  data  for  the  area  of 
operations  in  order  to  develop  a  long-range  path  plan.  Deliberative  planning  consists  of  separate 
layers  to  independently  assess  costs  for  traversing  terrain  in  the  context  of  mission  constraints  to 
include  point-to-point  mobility,  time  to  arrive,  coverage  of  co-combatants,  exposure  to  potential 
threats,  and  presence  of  confirmed  threats.  Those  layers  are  combined  using  a  weighted  heuristic 
into  a  single  planning  layer  for  use  by  the  route  planning  algorithm.  Different  weight 
combinations  map  into  various  tactical  concepts,  which  allow  the  user  to  specify  explicit  choices 
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such  as  “prefer  roads”  or  “stealth”;  weights  can  be  individually  set  during  experimentation. 
Deliberative  and  perceptive  level  planning  are  integrated  through  the  field  cost  interface  (FCI). 

Perceptive  planning  generates  local  paths  for  the  vehicle  to  follow  at  a  rate  of  ~5  Hz.  The 
maximum  planning  distance  for  local  paths  is  60  m,  which  is  limited  by  the  range  of  the 
vehicle’s  sensors.  The  perceptive-level  planner  follows  the  long-range  plan  by  navigating  to  the 
first  route  point  that  is  more  than  60  m  away  from  the  vehicle.  When  the  vehicle  is  within  60  m 
of  the  current  route  point,  the  perceptive  layer  planner  picks  a  point  in  its  search  graph  closest  to 
the  route  point  and  selects  the  cheapest  out  of  all  possible  trajectories  from  the  vehicle  to  that 
point.  The  cheapest  trajectory  is  chosen  based  on  its  cost,  which  takes  into  consideration  several 
parameters,  such  as  length,  terrain  complexity,  presence  of  obstacles,  and  others.  With  this 
approach,  the  vehicle  attempts  to  follow  the  long-range  plan  as  closely  as  it  can  because  the 
vehicle  is  always  trying  to  get  to  some  point  on  the  plan.  If  the  operator  does  not  initiate  a 
replan,  the  long-range  plan  does  not  change  throughout  the  course  of  the  mission. 

FCI  is  a  feature  that  provides  a  bridge  between  deliberative  layer  planning  and  perceptive  layer 
(local)  planning  by  generating  a  so-called  “cost  field,”  a  set  of  costs  to  get  from  any  point  on  a 
60-m  radius  circle  centered  at  the  vehicle  to  the  next  waypoint  (specified  by  the  operator).  The 
perceptive  planner  provides  the  set  of  costs  to  get  from  the  vehicle’s  location  to  all  points  along 
the  perimeter  of  the  sensor  range.  To  choose  where  to  go,  FCI  combines  these  two  costs:  the 
cost  to  get  from  where  the  vehicle  is  to  some  point  on  the  sensor  range  perimeter  (call  that  point 
A);  and  the  cost  to  get  from  A  to  the  next  mission  waypoint.  FCI  tells  the  vehicle  to  navigate  to 
the  point  along  the  perimeter  of  the  sensor  range  that  yields  the  cheapest  combination  of  local 
and  long-range  costs.  So  FCI  permits  navigation  to  virtually  any  point  on  the  sensor  range 
perimeter.  This  is  the  key  difference  between  FCI  and  the  perceptive  layer  planner.  Unlike  the 
perceptive  layer  planner,  FCI  does  not  provide  a  set  of  long-range  route  points  for  the  perceptive 
planner  to  follow  but  continually  follows  the  point  on  the  sensor  range  perimeter  that  possesses 
the  cheapest  local  and  long-range  combined  cost.  The  advantage  of  FCI  is  that  it  does  not  force 
the  vehicle  to  follow  a  fixed  long-range  plan,  giving  it  more  flexibility  to  deviate  from  moving 
directly  toward  the  goal  in  order  to  avoid  local  obstacles.  Therefore,  FCI  acts  as  a  guide  for 
XUV  mobility. 

In  order  to  tie  the  different  planners  together,  the  XUV  has  an  onboard  autonomous  command 
and  control  (ACC)  component.  Figure  36  shows  where  the  ACC  fits  into  the  XUV  software 
architecture.  The  ACC  allows  the  XUV  to  remain  aware  of  the  mission  and  global  environment 
by  providing  an  interface  between  the  world  model  of  a  priori  elevation  and  terrain  feature  data, 
the  perception  level  of  autonomous  mobility,  the  low-level  XUV  control  (via  the  XAC),  and  the 
status  of  the  XUV.  The  ACC  also  provides  the  XUV  with  the  ability  to  adapt  to  its  environment 
without  Soldier  intervention. 
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Figure  36.  XUV  software  architecture  showing  the  ACC  component. 

The  motivation  for  the  assessment  work  is  to  enable  the  XUV  to  use  the  best  information 
available  from  multiple  sources  (best  information  planning  [BIP])  and  to  bridge  the  deliberative 
and  perceptive-level  planning  such  that  the  unmanned  ground  vehicle  has  the  ability  to  use 
terrain  features  to  tactical  advantage  including  planning  its  way  out  of  untraversable  situations 
and  avoiding  entering  into  those  situations.  For  the  present  technology  assessment,  BIP  is 
confined  to  the  use  of  sensed  data  flowing  up  from  the  perceptive  level  to  update  the  deliberative 
planning  map  and  replanning  at  the  deliberative  level  based  on  the  updated  map.  The  XUV  did 
not  have  a  “data  gathering  mode”  where  it  explicitly  traversed  the  terrain  and  perfonned  full 
scans  with  its  LADAR  to  gain  complete  knowledge  of  the  surroundings.  The  information 
obtained  on  local  obstacles  for  BIP  purposes  was  derived  from  the  primary  autonomous  mobility 
sensor,  the  LADAR,  as  the  XUV  traversed  terrain.  Therefore,  sensed  obstacles  were  only 
acquired  where  the  XUV  happened  to  “look.” 

3.2  The  2008  Interplay  of  Multiple-Level  Planning  Assessment  Approach 

In  order  to  assess  the  impact  of  the  perceptive  and  deliberative  planning,  and  of  the  interplay  of 
these  two  technologies,  on  the  ability  of  the  XUV  to  maneuver  through  relevant  terrain,  a  series 
of  four  evaluations  were  conducted  at  Ft.  Indiantown  Gap  in  training  areas  Al,  B9C,  B12,  and 
C4.  The  first  approach  was  to  leverage  structured  environment  in  areas  Al,  B9C,  and  B12, 
where  a  combination  of  run  conditions  could  be  exercised  and  the  resultant  behavior  from  the 
XUV  observed.  The  second  approach  was  to  operate  in  area  C4  and  allow  the  XUV  more 
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latitude  in  path  selection  in  order  to  detennine  if  the  FCI  would  enable  the  XUV  to  find 
alternative  routes  to  the  goal  in  the  event  that  the  original  route  plan  could  not  be  achieved. 

This  assessment  of  information  planning  technologies  consisted  of  one  XUV,  one  operator  using 
an  OCU,  a  safety  chase  vehicle  with  a  driver  and  a  safety  officer  (with  an  E-stop  radio),  and  a 
data  recorder  for  noting  observations  for  each  run.  All  runs  consisted  of  a  starting  waypoint  and 
an  ending  waypoint  with  no  intennediate  waypoints  provided.  In  the  cases  where  a  priori 
elevation  and  feature  data  were  used  in  the  generation  of  an  initial  route  plan,  the  planner 
generated  route  points  to  be  achieved  along  that  route.  Feature  data  used  in  the  assessment 
consisted  of  tree  lines,  some  roads,  and  “no-go”  areas  that  contained  features  which  could  hann 
the  XUV  (e.g.,  water  hazards,  stumps).  In  the  event  that  the  XUV  could  not  plan  a  route  around 
an  obstacle  or  out  of  a  cul-de-sac,  the  XUV  autonomously  backed  up  to  gain  a  better  perspective 
of  the  environment  and  subsequently  attempted  to  use  perceptive  level  planning  to  find  a  suitable 
path.  This  programmed  behavior  was  attempted  up  to  three  times  with  the  distance  of  the 
backup  increasing  with  each  attempt  (5,  10,  and  15  m).  If  after  the  third  backup  the  XUV  was 
still  unable  to  plan  a  route  beyond  the  obstacle,  the  condition  was  referred  to  as  “maximum 
backups”  whereupon  the  operator  was  notified  to  intervene.  Options  for  operator  intervention 
depended  on  run  configuration.  In  runs  that  were  based  on  perceptive  level  planning,  the 
operator  was  required  to  teleoperate  the  vehicle  past  the  most  immediate  obstacle  and  then 
reexecute  the  original  route  plan  from  that  location.  For  runs  that  included  deliberative  level 
planning,  the  operator  initiated  a  15  m  backup  and  the  generation  of  a  new  route  plan  based  on 
data  sensed  from  the  local  area  and  a  priori  elevation  and  feature  data. 

3.3  Autonomous  Maneuver  Courses  Used  in  the  2008  Assessment 

3.3.1  Area  A1 

Area  A1  is  characterized  by  relatively  flat  terrain,  with  open  ground  being  more  grassland;  trees 
and  brush  occur  in  patches  and  dense  woods  and  marshy  areas  are  present.  Figure  37  shows  the 
course  layout  for  area  A1  which  consisted  of  natural  and  man-made  obstacles,  as  well  as  some  a 
priori  feature  data  for  marshy  and  wooded  areas.  The  condition  depicted  in  the  figure  shows  a 
planned  straight  path  that  is  -300  m  long  that  runs  between  the  start  point,  A,  and  end  point,  B, 
which  is  expected  for  a  run  that  does  not  rely  on  any  a  priori  data.  For  the  condition  where  the 
initial  route  plan  is  generated  based  on  a  priori  elevation  and  feature  data,  the  planned  route 
directed  the  XUV  to  weave  through  a  course  of  obstacles.  The  man-made  obstacles  consisted  of 
an  apparatus  constructed  of  tarps,  stakes,  and  cables  in  order  to  present  a  wall  through  which  the 
XUV  would  not  plan.  Figure  38  is  a  picture  of  one  of  these  structures  that,  in  conjunction  with 
nearby  natural  obstacles,  creates  an  impenetrable  cul-de-sac.  This  structure  induced  into  the 
course  was  intended  to  highlight  the  path  choices  made  by  the  XUV  in  order  to  facilitate 
interpretation  of  the  selected  routes  and  minimize  the  number  of  E-stops  due  to  the  XUV 
attempting  to  drive  through  sparsely  wooded  and/or  marshy  areas. 
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Figure  37.  Assessment  layout  for  area  Al. 


Figure  38.  Tarp  structure  used  to  create  cul-de-sac  in  area  Al. 


3.3.2  Area  B9C 

The  portion  of  area  B9C  used  in  this  assessment  consists  of  a  relatively  flat,  open  area  of 
approximately  three  acres  that  contains  numerous  shipping  containers  arranged  in  such  a  way  as 
to  simulate  a  small  military  operations  on  urbanized  terrain  (MOUT)  site.  Figure  39  is  a  sketch 
of  the  MOUT  site  which  is  constructed  from  steel,  dry  freight  shipping  containers  of  two  lengths, 
20  and  40  m,  and  with  a  cross  section  that  is  8  x  8  ft. 
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Figure  39.  Assessment  layout  for  area  B9C. 

The  start  and  end  points  for  each  run  are  depicted  as  A  and  B,  respectively,  and  the  initial  path 
for  all  runs  was  the  dashed  straight  line  path  shown  in  orange.  No  a  priori  feature  data  was  used 
for  this  portion  of  the  assessment  and  therefore,  none  of  the  MOUT  site  features  were  used 
during  the  generation  of  route  plans.  In  order  to  bound  the  problem,  a  boundary  line,  shown  in 
the  figure  as  a  blue  dashed  line,  was  entered  into  the  a  priori  data  to  prevent  the  XUV  from 
planning  a  route  that  circumvented  the  MOUT  site.  Although  for  this  scenario  it  would  appear 
that  the  better  route  to  the  goal  is  to  avoid  the  containers  altogether,  this  option  was  removed  so 
that  we  might  assess  the  ability  of  multilevel  mobility  planning  technologies  to  enable  the  XUV 
to  plan  a  way  out  of  a  cul-de-sac.  Additional  man-made  obstacles  in  the  form  of  construction 
barrels,  and  eventually  the  tarps  used  in  area  Al,  were  added  to  create  mobility  obstructions. 

The  geometry  of  the  MOUT  site  layout  was  tight  with  respect  to  the  XUV  turning  radius.  This 
area  did  afford  multiple  alternative  routes  that  were  available  to  the  XUV  in  order  to  achieve  the 
end  point. 

3.3.3  Area  B12 

The  mobility  planning  technologies  were  also  assessed  in  a  portion  of  training  area  B12. 

Figure  40  shows  the  area  of  operations  which  contains  open  fields,  tree  lines,  and  unimproved 
trails.  This  area  provided  another  opportunity  to  create  a  cul-de-sac  in  a  more  open  environment 
in  comparison  to  that  of  area  B9C.  A  combination  of  tarps,  construction  barrels,  and  HMMWVs 
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were  used  to  block  the  initial  planned  path  of  the  XUV  (figure  40).  The  width  of  the  cul-de-sac 
was  -50  m  which  provided  plenty  of  room  for  the  XUV  to  maneuver.  The  planned  route  was  the 
straight  line  path  shown  in  orange  and  was  -400  m  in  length.  The  alternative  route,  shown  in 
green,  was  a  traversable  route  to  the  goal  over  an  unimproved  trail  that  was  part  of  the  a  priori 
data. 


Figure  40.  Assessment  layout  for  area  B12. 

3.3.4  Area  C4 

Area  C4  is  characterized  by  rolling  vegetated  terrain,  unimproved  trails,  and  improved  trails. 

The  off-trail  terrain  was  dense  and  posed  the  additional  challenge  to  mobility  of  numerous  tree 
stumps  as  a  result  of  clear  cutting  activity.  The  motivation  for  using  the  selected  portion  of  this 
training  area  was  to  assess  the  multilevel  path  planning  technologies  in  a  less  structured 
environment.  Figure  41  shows  the  area  of  operations  with  the  planned  route  as  a  straight  line 
path  between  the  start  and  end  points  and  -500  m  long.  Boundary  lines  were  established  in  the  a 
priori  data  parallel  to  the  planned  path  along  the  road  to  the  right  and  to  the  left  at  -200  yd  from 
the  planned  path.  These  boundaries  were  necessary  to  prevent  the  XUV  from  planning  and 
maneuvering  on  the  road  and  among  the  tree  stumps,  respectively.  Additionally,  a  no-go  area 
was  established  around  a  pond  that  was  within  the  boundary  lines.  A  no-go  area  is  defined  in  the 
perceptive  layer  map  such  that  the  area  may  be  considered  for  route  planning  at  the  deliberative 
layer,  but  the  vehicle  will  not  enter  the  area  due  to  the  restriction  at  the  perceptive  level. 
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Figure  41.  Assessment  layout  for  area  C4. 

3.4  Experimental  Design 

The  assessment  conducted  in  each  of  the  described  areas  was  based  on  a  schedule  of  runs  which 
varied  the  available  conditions.  Primarily  the  available  parameters  for  variation  in  run  conditions 
included  slight  variation  of  the  start  and  end  locations,  inclusion/exclusion  of  available  a  priori 
elevation  and  feature  data,  and  the  inclusion/exclusion  of  the  BIP  and  FCI  path  planning 
technologies.  Limitations  due  to  the  weather  and/or  difficult  terrain  imposed  constraints  on  the 
number  of  possible  parameter  variations  and  will  be  discussed  in  the  Observations  section  (3.8) 
of  this  report. 

3.5  The  2008  Assessment  Operations 

The  configuration  for  each  run  was  established  by  an  engineer  prior  to  the  start  of  the  run  using  a 
laptop  computer  to  run  configuration  script  files  and  transmit  the  appropriate  configuration 
commands  to  the  XUV  via  a  wireless  local  area  network  link.  Each  run  began  with  the  XUV 
located  at  the  start  point  and  oriented  towards  the  end  point.  The  operator  used  the  OCU  to 
generate  a  route  plan  using  one  waypoint  for  the  start  location,  one  waypoint  for  the  end  location, 
and  a  cross-country  route  type,  which  resulted  in  a  straight  line  route  (except  for  part  of  the  area 
A  assessment  wherein  a  priori  data  was  used)  that  was  through  tree  lines  and  other  impenetrable 
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obstacles  for  at  least  a  portion  of  the  route.  The  reason  for  establishing  a  planned  route  that  did 
not  consider  available  elevation  and  feature  data  was  twofold.  Firstly,  it  is  realistic  to  expect  that 
map  data  available  to  maneuver  forces  could  contain  errors  due  to  limitations  of  resolution  and 
inaccurate/missing  features.  The  second  reason  to  prescribe  such  a  route  was  to  challenge  the 
XUV  to  use  its  autonomous  mobility  capabilities  and  the  multilevel  path-planning  technologies 
to  execute  a  suitable  path  to  the  goal. 

Upon  receiving  the  route  plan  and  the  command  to  execute,  the  XUV  proceeded  to  maneuver 
towards  the  goal.  During  the  runs,  the  XUV  sent  status  update  messages  to  the  OCU  that 
indicated  to  the  operator  the  current  command  being  executed,  error  messages,  and  system 
diagnostic  data  (e.g.,  fuel  level).  A  complete  log  fde  of  this  infonnation  was  captured  and  saved 
for  each  run  performed.  In  the  event  that  the  XUV  encountered  an  obstacle  in  its  path,  the 
procedure  was  for  the  XUV  to  autonomously  attempt  to  maneuver  around  the  obstacle  in  order  to 
proceed.  In  order  to  facilitate  finding  a  suitable  path  around  obstacles,  the  assessment  protocol 
required  the  XUV  to  follow  the  previously  described  backup  procedure  in  an  attempt  to  gain  a 
better  perspective  for  the  perception  sensors.  If  the  XUV  found  a  suitable  path  around  an 
obstacle,  the  system  would  autonomously  execute  that  path.  If,  after  three  attempts  to  backup, 
the  XUV  was  unable  to  find  a  path,  then  an  operator  intervention  request  was  sent  to  the  OCU 
and  the  previously  described  intervention  procedure  followed. 

In  the  event  that  an  emergency  stop  was  declared  due  to  potential  for  unsafe  operation,  at  that 
point  the  end  of  the  run  was  declared.  In  some  instances,  for  the  sake  of  completeness  and/or 
troubleshooting,  the  XUV  was  teleoperated  past  the  trouble  spot  and  the  run  resumed. 

3.6  Data  Collection 

Data  collected  included  the  SMI  log,  ACC  log,  mission  plan,  and  a  screenshot  from  the  end  of 
the  run.  Observations  on  the  behavior  of  the  XUV  and  the  interaction  of  the  operator  were 
manually  collected  by  the  data  recorder. 

3.6.1  SMI  Log  Sample 

Figure  42  shows  an  excerpt  from  the  SMI  log  for  one  run.  The  SMI  log  provides  a  record  of  the 
instructions  sent  by  the  operator  from  the  SMI  to  the  XUV  and  messages  sent  to  the  operator. 

3.6.2  ACC  Log  Sample 

An  excerpt  from  the  ACC  log  file  for  one  of  the  multilevel  path-planning  runs  is  shown  in 
figure  43.  The  table  reflects  the  messaging  between  the  various  parts  of  the  control  software 
architecture. 
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00: 10:48.26  si  Button  pressed  [Select  Plan]  (select  plan)  =  selected 
00: 10:51.26  si  selected  plan  areaCroadroute 
00:10:51.97  si  Button  pressed  [Select]  (select)  =  unselected 
00:10:54.27  si  Button  pressed  [Assign]  (assign)  =  selected 
00: 10:56.95  si  selected  asset  XUV1 1 

00:10:57.33  si  Button  pressed  [Assign]  (assign)  =  unselected 
00:11:42.12  si  XUV11  sent:  (ramp  XUV 
(move-on-route  max-speed  4.40 
(tolerance  30.00) 

(radius  28.09) 

(route  cross-country 

(Z18N  4478774.0  362267.6  204.0  0x3) 

(4478781.5  362265.1  205.0  0x4000000) 

(4478786.0  362261.1  204.9  0x4000000) 

(4478818.0  362231.1  204.4  0x4000000) 

(4478875.0  362180.3  205.9  0x4000000) 

(4478938.0  362126.9  206.6  0x4000000) 

(4478948.0  362121.5  207.1  0x4000000) 

(4479062.5  362061.1  212.4  0x4000000) 

(4479113.0  362036.9  213.3  0x4000000) 

(4479133.0  362031.1  213.5  0x4000001) 

(4479138.0  362026.1  213.4  0x4000001) 

(4479148.0  362011.9  213.3  0x4000001) 

(4479213.0  361916.1  213.9  0x4000000) 

(4479223.0  361897.2  214.6  0x4000000) 

(4479262.0  361833.3  223.0  0x1) 

00:11:42.12  si  Button  pressed  [Execute  Plan]  (execute  plan)  =  unselected 
00:11:42.68  si  XUV11  working  towards  wp  1 
00:11:42.68  si  XUV11  state  change  Running 

00:11:46.86  si  Wca:  XUV1 1  Caution,  -  Vehicle  is  out  of  path  bounds! 

00:12:05.04  si  XUV11  working  towards  wp  2 

00:12:25.40  si  Wca:  XUV1 1  Caution,  -  Vehicle  is  out  of  path  bounds! 

00: 12:25.54  si  XUV1 1  backing  up 

00:12:26.04  si  XUV11  done  backing  up _ 


Figure  42.  Excerpt  from  SMI  log  file. 
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15:39:17.01661  |  0  |  XACConnection.cpp[501]::ReadXuvStatus  XUV  Status  buffer  WAS  read 
15:39:17.01666  |  0  |  XACConnection.cpp[678]::ProcessIncomingMessage  stat  msg  received 
15:39:17.01684  |  0  |  XACConnection.cpp[324]::ListenFunc:  Calling  ReadAndProcess()  for  sensed  data. 
15:39:17.01825  |  0  |  smi_mi.cpp[243]::lnterpretMessage  Incoming  Unit  ID:  8404747 
15:39:17.01838  |  1  |  MessageAdapterlnterface.cpp[259]::ListenFunction  Message  Adapter  external  message 
interpretation  and  send  was  successful 

15:39:17.01999  |  1  |  KBModuleLoader.cpp[270]::Execute  knowledgebase  executed  2  rules 
15:39:17.02015  |  0  |  tr_interface.cpp[564]::OnReceive  thread  pid  5280 

15:39:17.02022  |  0  |  tr_interface.cpp[603]::OnReceive  received  Unit  message  ->  notifying  geoplanner 
15:39:17.02044  |  0  |  smi_mg.cpp[99]::GenerateMessage  Not  sending  object  to  SMI  because  it  has  not  changed.... 
15:39:17.02051  |  0  |  MessageAdapterInterface.cpp[295]::OnReceive  Message  Adapter  external  message 
generation,  externalMessage  was  NULL 

15:39:17.02060  |  0  |  tr_interface.cpp[1038]::FillBso  muid:  8404747,  name;  XUV11,  affd:  1,  lookup:  0 
15:39:17.02067  j  0  |  tr_interface.cpp[1110]::FillBso  fdled  bso  from  registered  asset  type 
15:39:17.02077  j  0  |  tr_interface.cpp[l  148]::FillBso  filled  bso  is:  Bso:: 

Id:  8404747,  Name:  XUV11,  NatoType:  66,  PlanType:  NONE,  Affil:  FRND, 

Height:  2.00,  Active:  1,  18  363377.69E  4475508.00N  El:  143.33 
Orientation:: 

heading:  174.875428,  pitch:  -0.630254,  roll:  -2.234535,  Sensor::  Type:  0,  range:  1500.000000,  GetRange(): 
1500.000000,  hfov:  360.000000,  vfov:  180.000000,  0  0.00E  0.00N  El:  2.00  Orientation::  heading:  0.000000, 
pitch:  0.000000,  roll:  0.000000, 

15:39:17.02088  |  0  |  tr_interface.cpp[845]::NotifyGeoplannerFacade  Updating  bso  to  geoplanner. 

15:39:17.23182  j  1  j  KBModuleLoader.cpp[273]::Execute  knowledgebase  executed  0  rules 
15:39:17.94799  |  0  |  XACConnection.cpp[328]::ListenFunc:  Returned  from  ReadAndProcess(). 

15:39:17.99955  |  0  |  NMLConnectionlnterface.cpp[640]::ReadNML  reading 
Buffer  xlpdata 


Figure  43.  Excerpt  from  ACC  log  file. 

3.6.3  Screenshot  Sample 

At  the  end  of  each  run,  an  image,  referred  to  as  a  screenshot,  of  the  OCU  screen  was  saved  to 
disk  (see  figure  44).  This  image  provides  a  record  of  the  planned  path,  the  path  traveled  by  the 
XUV,  and  any  imposed  boundaries,  a  priori  tree  line  data,  and  no-go  areas. 

3.7  Data  Reduction 

Dependent  measures  for  each  run  included  the  number  of  backups,  number  of  times  maximum 
backups  was  reached,  number  of  E-stops  for  each  type  (administrative  E-stop  or  safety  E-stop), 
number  of  required  teleoperations,  and,  in  the  case  where  BIP  and/or  FCI  were  included,  an 
indication  of  whether  or  not  the  planning  technology  helped  the  XUV  to  proceed. 

3.7.1  Area  A1  Data 

The  schedule  of  runs  anticipated  for  area  A1  over  two  days  of  experimentation  is  shown  in 
table  5.  The  six  independent  variables  for  this  run  schedule  include  (1)  the  inclusion  of  a  prior 
elevation  and  feature  data  in  the  initial  route  plan  fonnulation  (indicated  in  the  planner  column), 
(2)  the  inclusion  of  BIP,  (3)  the  inclusion  of  FCI,  (4)  the  location  of  the  start  point  (A1  or  A2), 
(5)  the  location  of  the  end  point  (B1  or  B2),  and  (6)  the  presence  of  a  known  threat. 
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Figure  44.  Sample  screenshot  captured  at  the  end  of  each  mission  (black  area  on  map  indicates  no 
available  a  priori  map  data). 


The  conditions  at  the  time  of  the  assessment  were  such  that  moisture  in  the  ground  coupled  with 
a  warming  trend  caused  the  areas  surrounding  the  marshy  portion  of  area  A1  to  become 
increasingly  muddy  with  each  run.  This  condition  resulted  in  two  deleterious  effects  on  the 
ability  to  conduct  the  assessment.  The  first  effect  was  the  wheel  slippage  of  the  XUV  due  to  the 
mud.  Encoders  on  each  wheel  of  the  XUV  are  used  to  determine  the  relative  position  of  the 
vehicle  with  respect  to  the  objects  perceived.  As  a  result  of  the  wheel  slippage,  the  map  which 
contains  the  data  for  those  obstacles  became  smeared  such  that  both  the  magnitude  and  location 
of  obstacles  are  incorrect.  The  resultant  behavior  is  the  XUV  attempts  to  avoid  the  numerous 
obstacles  in  the  map  that  are  actually  nonexistent.  The  second  effect  on  the  ability  to  conduct  the 
assessment  was  a  loss  of  chase  vehicle  traction,  also  due  to  the  mud.  As  the  conditions 
worsened,  the  safety  operator  was  required  to  initiate  numerous  E-stops  in  order  for  the  chase 
vehicle  to  catch  up  to  the  XUV. 
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Table  5.  Run  schedule  for  area  Al. 
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After  1.5  days  of  operations  in  area  Al,  six  accepted  runs  were  accomplished.  In  addition  to 
these  accepted  runs,  a  number  of  runs  were  reexecuted  in  order  to  complete  a  full  run  in  the 
presence  of  technical  complications.  Appendix  B  to  this  report  contains  summary  data  for  each 
run  perfonned  in  areas  Al,  B9C,  B12,  and  C4.  Table  B-l  provides  a  summary  of  measured  data 
for  ah  of  the  runs  performed  in  area  Al . 

3.7.2  Area  B9C  Data 

The  assessment  conducted  in  area  B9C  revealed  several  interesting  things  about  the  interplay  of 
the  perceptive  and  deliberative  planners  and  the  autonomous  mobility  of  the  XUV.  Table  6 
shows  the  run  schedule  that  was  used  for  this  area  and  over  two  days  in  the  held,  data  was 
obtained  for  eleven  accepted  runs  plus  four  reexecute  runs.  The  problem  with  map  smearing 
again  appeared  during  this  technology  assessment  however  the  cause  was  not  due  to  sloppy 
terrain  conditions  as  was  the  case  for  area  Al.  The  main  challenge  in  area  B9C  was  the 
relatively  narrow  corridors  resulting  from  the  close  layout  of  the  shipping  containers,  which 
constrained  XUV  mobility  requiring  numerous  backups  in  attempt  to  find  a  path.  During  the 
successive  backups  over  the  same  path,  the  height  map  in  the  perceptive  layer  exhibited  an 
artificial  growth  of  obstacles  on  the  ground  plane,  which  reached  the  minimum  obstacle  height 
and  thus  influenced  the  XUV  to  avoid  those  obstacles.  The  tight  geometry  also  prevented  the 
XUV  from  being  able  to  turn  around  in  the  cul-de-sac  and  executing  the  new  path.  On  one  run  it 
was  shown  that  when  the  XUV  was  able  to  turn  around,  the  new  path  based  on  updated  map  data 
enabled  the  XUV  to  achieve  the  goal  autonomously.  Another  interesting  situation  that  occurred 
in  the  cul-de-sac  involved  FCI.  When  the  XUV  attempted  to  follow  a  new  path,  which  ran  back 
within  the  XUV  sensor  range,  down  the  next  side  corridor  (see  figure  45)  and  around  to  the  goal, 
the  lowest  cost  action  for  the  XUV  to  continue  was  to  go  forward  (through  the  obstacle  to  the 
yellow  dot)  in  order  to  proceed  along  the  new  path.  Cost  is  measured  in  meters  to  go  around  an 
obstacle.  The  XUV  attempted  to  move  forward  based  on  the  deliberative  plan  but  could  not 
succeed  because  the  perceptive  level  planning  detected  the  obstacle  and  would  not  proceed.  The 
resultant  behavior  was  the  XUV  moving  forward  to  find  a  path,  backing  up  when  no  path 
through  the  obstacle  could  be  found,  and  repeating  this  behavior  until  maximum  backups  was 
reached.  Table  B-2  contains  summary  data  from  ah  runs  performed  in  area  B9C. 

3.7.3  Area  B12  Data 

The  technology  assessment  conducted  in  the  portion  of  area  B12  yielded  seven  accepted  runs  and 
one  reexecuted  run  over  1.5  days  in  the  held.  As  a  result,  several  interesting  behaviors  were 
exhibited  by  the  XUV.  The  runs  schedule  for  area  B12  is  provided  in  table  7.  The  need  for 
planning  technologies  that  enable  the  XUV  to  avoid,  or  extricate  itself  from,  obstructed  pathways 
was  exemplified  during  this  portion  of  the  technology  assessment.  During  the  runs  where  only 
the  perceptive  layer  was  used  (e.g.,  run  1),  the  XUV,  when  faced  with  an  obstructed  path,  would 
continually  perform  a  figure  eight  pattern  in  search  of  a  path  through  the  obstacle.  However 
when  BIP  was  enabled  (e.g.,  run  3)  and  given  sufficient  room  to  maneuver,  the  XUV 
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Table  6.  Run  schedule  for  area  B9C. 
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Figure  45.  Depiction  of  scenario  with  FC1  and  perceptive  level  planning  power  struggle. 


demonstrated  that  when  faced  with  an  obstructed  route  it  had  the  ability  to  apply  BIP  to  plan  and 
execute  an  alternative  route  to  avoid  the  obstruction  and  continue  to  the  end  point.  The  behavior 
that  was  observed  in  area  B9C  wherein  the  perceptive  layer  detected  obstacles  yet  the 
deliberative  layer  planned  through  those  same  obstacles  was  also  seen  during  the  assessment  in 
area  B12.  It  was  apparent  during  more  than  one  run  that  the  priority  given  to  either  the 
perceptive  layer  or  the  deliberative  layer  to  drive  mobility  has  a  significant  influence  on  the 
ability  of  the  XUV  to  maneuver  in  the  presence  of  obstructed  pathways.  Technical  difficulties 
with  the  FCI  demonstrated  the  need  for  further  refinement  to  increase  the  robustness  of  that 
technology.  Table  B-3  contains  summary  data  for  the  runs  performed  in  area  B 12. 
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Table  7.  Run  schedule  for  area  B12. 
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3.7.4  Area  C4  Data 

The  schedule  of  runs  for  area  C4  is  shown  in  table  18.  After  1.5  days  of  assessment,  1 1  accepted 
runs  and  one  reexecuted  run  were  perfonned.  The  results  for  this  portion  of  the  assessment  are 
provided  in  table  B-4.  During  the  runs  in  area  C4,  a  significant  amount  of  time  was  devoted  to 
finding  suitable  planned  routes  that  the  XUV  could  execute.  The  terrain  in  this  area  provided 
few  opportunities  for  the  XUV  to  explore  for  alternative  routes  due  to  the  presence  of  hazardous 
stumps  and  debris.  The  minimum  height  at  which  an  object  is  classified  as  an  obstacle  is  a 
parameter  that  is  defined  in  the  perceptive  layer  planner  code  and  can  be  changed  prior  to 
running  in  a  given  type  of  terrain.  For  area  C4,  the  setting  for  the  minimum  obstacle  height 
detennined  whether  the  XUV  would  drive  over  the  stumps,  as  in  the  case  when  the  minimum 
obstacle  height  setting  is  too  high  (e.g.,  1  m)  or  move  very  slowly  and  across  only  sparse  terrain, 
as  in  the  case  when  the  minimum  obstacle  height  setting  is  low  (e.g.,  0.5  m).  It  was 
demonstrated  that  when  the  XUV  entered  a  long,  narrow  path  leading  to  a  cul-de-sac,  BIP 
provided  an  exit  plan,  but  the  XUV  could  not  negotiate  a  turn  around  in  order  to  pursue  the  new 
path. 
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Table  8.  Run  schedule  for  area  C4. 
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3.8  Observations 

3.8.1  General 

The  scenarios  posed  to  the  XUV  during  the  nine  days  of  assessing  route  planning  technologies  in 
four  locations  enabled  the  research  team  to  discover  and  confirm  abilities  and  deficiencies  of  the 
path  planning  technologies.  In  addition,  there  were  numerous  technical  difficulties  that  arose 
during  the  time  in  the  field  that  the  technical  staff  will  have  opportunity  to  address  prior  to  the 
next  assessment. 

Weather  and  rough  terrain  posed  a  significant  challenge  to  obtaining  a  quantity  of  meaningful 
data.  Furthennore,  the  balance  between  choosing  a  minimum  obstacle  classification  height,  that 
takes  into  account  the  need  to  provide  safety  for  the  XUV  and  enable  the  XUV  to  maneuver  off¬ 
road,  is  an  area  that  requires  further  investigation. 

3.8.2  The  Interplay  of  Planning  at  Multiple  Levels 

The  interplay  between  the  perceptive  and  deliberative  planners  was  shown  to  have  a  significant 
impact  on  the  behavior  of  the  XUV  when  attempting  to  maneuver  in  the  presence  of  obstructed 
pathways.  The  challenge  is  that  if  the  perceptive  layer  is  too  conservative  in  the  way  that  it 
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identifies  obstacles,  path  planning  of  the  XUV  will  likely  result  in  avoiding  pathways  that  the 
XUV  could  traverse;  however,  if  the  deliberative  layer  has  the  final  say  in  the  executed  route,  the 
XUV  is  likely  to  enter  into  terrain  that  could  potentially  damage  the  vehicle.  More  work  is 
required  in  developing  the  ability  of  the  XUV  to  seamlessly  use  sensed  and  a  priori  data  to 
efficiently  maneuver  in  this  type  of  terrain. 

3.8.3  BIP 

BIP  planning  provided  a  path  that  would  enable  an  exit  to  man-made  and  natural  cul-de-sacs  that 
otherwise  the  XUV  could  not  have  overcome.  It  was  shown  that  when  mobility  was  confined 
such  that  the  XUV  could  not  turn  around  in  the  cul-de-sac,  it  was  unable  to  execute  a  new  path. 

3.8.4  FCI 

The  FCI  provided  freedom  to  the  XUV  to  search  for  suitable  paths  to  the  goal  as  designed. 
However,  more  effort  is  required  to  provide  a  reasonable  set  of  scenarios  and  a  corresponding 
data  set  that  will  provide  insight  as  to  the  effectiveness  of  this  technology  to  enable  the  XUV  to 
avoid  obstructed  pathways.  The  LADAR  has  a  maximum  range  of  60  m  and  the  surrounding 
terrain  frequently  obstructs  the  XUVs  line  of  sight.  This  limitation  prevents  FCI  from  planning 
around  obstacles  beyond  the  LADAR  sensor  range.  This  is  important  since  the  ACC  portion  of 
FCI  plans  from  60  m  out  to  the  next  way  point.  With  a  longer  range  sensor,  FCI  (with  BIP) 
should  be  able  to  foresee  cul-de-sac  conditions  and,  as  a  result,  avoid  entering  them. 

3.9  Recommendations  From  the  Interplay  of  Multiple-Level  Planning  Assessment 

3.9.1  General 

1 .  Investigate  additional  scenarios  for  evaluating  the  interplay  of  multilevel  planning 
technologies.  Although  a  variety  of  terrain  was  used  in  this  assessment,  the  scenarios  used 
to  evaluate  the  interaction  between  the  perceptive  and  deliberative  planning  layers  were 
limited  to  two  situations.  A  greater  variety  in  scenarios  is  recommended  to  better 
determine  the  performance  and  efficacy  of  these  technologies. 

2.  Consider  alternatives  to  backup  procedures.  The  current  method  of  using  three  consecutive 
backups  prior  to  calling  the  operator  to  intervene  is  time  consuming  and  of  questionable 
benefit.  It  is  recommended  that  the  backup  procedure  be  updated  to  consider  current 
capabilities  in  XUV  mobility. 

3.  Develop  algorithms  that  enable  the  XUV  to  maneuver  in  the  presence  of  confining  terrain 
features.  In  situations  where  a  new  plan  based  on  sensed  data  requires  the  XUV  to  perfonn 
sharp  turns  in  order  to  begin  traversing  the  new  path,  this  requires  greater  mobility  than  the 
current  implementation  provides. 


53 


4.  Leverage  hardware-in-the-loop  simulations.  Prior  to  a  field  assessment,  the  algorithm 
developers  need  an  opportunity  to  run  a  number  of  scenarios  in  order  to  perfonn  a 
parametric  study  on  the  effect  of  the  various  run  configurations.  This  will  increase  the 
effectiveness  of  the  field  assessments  and  better  prepare  the  technology  for  evaluation. 

5.  Remove  software  developers  from  being  in-the-loop  during  the  next  assessment.  The 
establishment  of  necessary  parameters  for  each  run  should  be  performed  by  the  operator. 
This  should  include  the  ability  to  specify  a  minimum  obstacle  height.  Furthermore,  no 
parameters  that  affect  the  performance  of  the  underlying  algorithms  should  be  changed 
during  the  course  of  a  run. 

3.9.2  Interplay  of  Perceptive  and  Deliberative  Planners 

Continue  to  work  on  the  interaction  between  the  perceptive  layer  and  deliberative  layer  planners. 
The  handoff  between  the  perceptive  and  deliberative  planning  layers  requires  further  attention. 

A  method  is  required  to  ensure  that  available  terrain  feature  information  is  used  appropriately  by 
both  layers  so  that  the  vehicle  does  not  avoid  a  path  that  affords  safe  mobility  and  can  effectively 
identify  when  a  path  is  blocked  or  is  too  narrow  that  mobility  becomes  inherently  unsafe. 

3.9.3  BIP 

Increase  the  autonomy  with  which  the  XUV  uses  BIP.  It  is  recommended  that  planning  based  on 
sensed  infonnation  be  automated  for  the  next  assessment  by  removing  the  step  that  requires  the 
operator  to  initiate  a  replan.  The  implications  of  this  automation  for  the  operator  will  need  to  be 
explored  in  future  assessments.  Also,  it  is  recommended  that  the  XUV  actively  perform  a  more 
complete  scan  of  the  environment,  as  it  traverses  terrain,  in  order  to  improve  the  quality  of  a  new 
deliberative  plan  that  is  based  on  sensed  information. 

3.9.4  FCI 

More  effort  is  required  to  determine  the  efficacy  of  the  FCI.  The  robustness  of  this  technology  to 
perform  as  designed  during  field  experimentation  must  improve  in  order  to  assess  its  influence 
on  vehicle  behavior.  It  is  further  recommended  that  simulation  be  leveraged  to  better  understand 
the  numerous  parameters  that  influence  the  performance  of  the  FCI. 

3.9.5  Technology  Assessment 

1 .  Continue  to  investigate  available  areas  for  future  assessments.  More  effort  is  required  to 
identify  and  use  available  terrain  for  assessments  of  these  mobility  planning  technologies. 

If  the  fidelity  of  the  suggested  software-in-the-loop  simulation  is  sufficient  to  accurately 
represent  terrain  features  and  elevation,  that  effort  may  be  leveraged  to  estimate  the  impact 
of  terrain  selection  for  future  field  experimentation. 
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2.  Establish  useful  metrics  for  unmanned  ground  vehicle  performance.  In  order  to  assess  the 
ability  of  an  unmanned  ground  vehicle  to  maneuver  in  a  tactical  manner  through  relevant 
terrain,  a  set  of  criteria  is  required  to  measure  performance.  Although  summary  data  as 
that  provided  in  appendix  B  can  be  used  to  draw  some  limited  qualitative  conclusions,  a 
means  to  quantitatively  measure  the  ability  of  the  vehicle  to  behave  in  a  way  that  would 
benefit  the  Soldier  is  warranted. 


4.  Summary 


During  4-14  February  2008,  ARL  and  General  Dynamics  Robotics  Systems  conducted  an 
assessment  of  technologies  designed  to  enable  tactical  unmanned  ground  vehicle  behaviors.  The 
assessment  provided  data  taken  in  a  relevant  environment  that  demonstrated  the  ability  to  use 
sensed  infonnation  to  locally  orient  the  platform  in  order  to  obtain  line  of  sight  for  an  onboard 
RSTA  system  to  scan  a  sufficient  portion  of  a  named  area  of  interest  and  the  impact  of  advances 
in  deliberative  layer  planning  technologies  to  enhance  autonomous  mobility  in  a  relevant 
environment. 

The  OP  finders  and  the  HMP  combined  to  successfully  demonstrate  that  locally  sensed  terrain 
and  feature  data  can  be  successfully  utilized  to  find  and  move  the  XUV  to  an  OP  location  with 
improved  visibility  to  the  NAI.  Both  approaches  for  finding  a  suitable  OP  perfonned  sufficiently 
well  to  continue  their  advancement. 

As  a  result  of  this  technology  assessment,  it  was  shown  that  the  interplay  between  the  perceptive 
and  deliberative  planning  layers  plays  an  important  role  in  vehicle  path  planning  but  requires 
further  development.  More  refinement  is  required  in  order  for  the  XUV  to  seamlessly  use  sensed 
and  a  priori  data  to  efficiently  maneuver  in  relevant  terrain. 

Specific  recommendations  for  the  methodology  and  functionality  of  select  technologies  were 
provided  to  facilitate  enhancement  of  future  field  activities.  The  infonnation  and  experience 
provided  to  the  software  developers  and  the  designers  as  a  result  of  the  2008  technology 
assessment  will  be  applied  to  focus  research  in  vehicle  path  planning,  improve  the  functionality 
of  technology  components,  and  improve  the  quality  of  future  technology  assessments. 
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Following  the  February  2008  assessment  described  in  the  body  of  this  report,  an  infonnal 
discussion  was  held  with  an  active  duty  Army  Master  Sergeant  to  discuss  potential  alternatives 
for  implementing  an  automated  process  for  observation  post  finding.  Figures  A1-A5  graphically 
summarize  the  resulting  process. 

The  first  step  of  the  process  is  the  experimental  unmanned  vehicle  (XUV)  stops  short  of  the 
operator-input  OP  and  takes  an  automatic  reconnaissance  surveillance  target  acquisition  (RSTA) 
scan  so  that  the  operator  can  check  the  proposed  area  for  enemies  and  see  the  general  area  for 
possible  places  for  concealment  (see  figure  A-l).  At  that  location,  the  XUV  traverses  a  path  that 
enables  the  system  to  obtain  mid-range  obstacles  from  the  structure  from  motion  (SFM) 
algorithms.  The  XUV  then  moves  to  the  approximate  OP  given  by  the  operator.  The  operator 
should  be  given  status  messages  when  XUV  has  stopped  and  presents  RSTA  for  checking 
enemies  and  concealment  as  well  as  when  the  SFM  movement  is  taking  place. 

At  this  location,  the  XUV  laser  detection  and  ranging  (LADAR)  will  do  a  scan  and  calculate  the 
percent  coverage  of  the  named  area  of  interest  (NAI)  and  take  a  RSTA  image  (it  might  be  helpful 
to  have  the  linear  NAI  projected  on  the  RSTA  image.)  Also  at  this  time,  the  next  “top  five”  OP 
locations  are  calculated  based  on  some  combination  of  coverage  percent,  the  cost  to  make  an 
autonomous  move  to  the  location  (autonomous  mobility  costs  using  the  high-mobility  planner) 
(see  figure  A-2).  The  coverage  percent,  RSTA  image,  and  the  new  “top  five”  OP  locations  are 
presented  to  the  operator.  If  he  judges  the  current  location  to  be  a  good  OP,  then  the  process  of 
OP  finding  is  completed.  If  not,  the  operator  chooses  the  next  OP  from  the  “top  five”  list  and  the 
XUV  moves  to  that  location  (see  figure  A-3).  (It  might  be  helpful  to  the  operator  if  the  next  “top 
five”  OPs  could  be  projected  onto  the  given  RSTA  image.)  Appropriate  choice  selection  options 
and  status  messages  need  to  be  presented  to  the  operator  as  this  process  proceeds. 

This  process  is  repeated,  presenting  infonnation  to  the  operator  and  he  deciding  if  a  good  OP  or 
not  based  on  the  presented  RSTA  images  and  identified  “top  five”  potential  OPs  (see 
figure  A-4).  The  OP  finding  process  is  complete  when  the  operator  has  chosen  an  OP  and 
proceeds  with  his  RSTA  and  other  tasks. 

This  is  a  potential  OP  finding  process  that  puts  the  operator  at  the  center  of  decision  making, 
with  the  XUV  providing  automated  infonnation  and  moving  autonomously  based  on  the  operator 
decisions.  Figure  A- 5  presents  some  notes  that  add  to  the  graphical  summary  of 
figures  A-l-A-4.  Of  particular  note  is  that  a  threshold  criterion  of  coverage  percent  becomes 
inelevant  because  coverage  percent  for  every  point  is  calculated  and  the  operator  chooses  if  a 
move  to  a  new  point  is  required. 
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OP  Planner:  Find  a  location  near  the  OP  where  visibility  to  the  NAI  is 


Figure  A-l.  The  multistep  observation  post  finding  process  begins  with  stopping 
short  of  the  operator  input  OP  to  scan  for  possible  enemy  at  the  OP. 
If  no  enemy  is  sighted,  then  the  XUV  transverses  a  route  that  allows 
adding  midrange  obstacles  to  the  map. 


•  Stop 

1  .Do  scan  of  NAI,  report  %  coverage  at  own 
location  to  operator 

2.  Take  a  RSTA  picture  of  NAI  (project  NAI 
onto  RSTA  picture?) 

3.  Display  on  SMI  map  the  five  top  new  OPs 
based  on  {Coverage,  AM  cost,  and 
Concealment} 

■  Operator  decides  if  Good  OP  based  1  -3. 

•  Y-  done,  do  the  RSTA 

•  N-go  to  next  slide 


Figure  A-2.  The  multistep  process  continues  with  a  LADAR  scan  of  the  NAI  and 
a  report  to  the  operator  of  the  percent  coverage.  A  RSTA  image  is 
taken  and  displayed  to  the  operator.  The  five  “top”  Ops  are 
displayed  to  the  operator.  If  the  operator  judges  that  the  current 
position  is  good,  then  the  OP  finding  is  completed.  If  it  is  not  good, 
then  the  OP  finding  process  continues. 
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Figure  A-3.  If  the  operator  judges  that  the  current  position  is  not  good,  then  the 
operator  selects  a  new  OP  from  the  choice  of  five  presented  on  the 
SMI.  The  XUV  will  then  move  to  the  selected  new  OP  and  stops, 
pointed  toward  the  NA1. 


•  Stop 

1  .Do  scan  of  NAI,  report  %  coverage  at  own 
location  to  operator 

2.  Take  a  RSTA  picture  of  NAI  (project  NAI 
onto  RSTA  picture?) 

3.  Display  on  SMI  map  the  five  top  new  OPs 
based  on  {Coverage,  AM  cost,  and 
Concealment} 

•  Operator  decides  if  Good  OP  based  1-3. 

•  Y-  done,  do  the  RSTA 

•  N-repeat  the  process 


Figure  A-4.  At  this  new  OP,  the  process  is  repeated.  The  operator  is  presented  with  a 

RSTA  scan  of  the  NAI  and  five  new  “top”  OPs  and  makes  a  decision  on  the 
OP.  The  process  repeats  until  the  operator  is  satisfied  with  the  new  OP. 
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Proposed  OP  Finding  Process 


•  Process  only  stops  when  operator  is  satisfied 

•Operator  gets  knowledge  of  %  coverage  at  his  location,  looks  at  RSTA  scan, 
and  next  best  choices  to  decide  if  the  current  location  is  a  good  OP. 

•Always  get  the  top  five  OPs,  regardless  of  threshold.  Top  five  new  OPs  are 
picked  based  on  some  combination  of  %  coverage,  autonomous  mobility  cost  to  get 
there,  and  %  concealment . 

•Threshold  becomes  irrelevant.  Process  does  not  stop  when  no  good  OP  can 
be  found. 

•Operator  in-the-loop  adds: 

•Can  see  mid-range  obstacles 

•Can  pick  OP  with  best  possible  concealment 

•  Immediate  judgment  on  %  coverage  reported 

•  Picks  from  five  best  new  OPs 


Figure  A-5.  This  proposed  multistep  OP  finding  process  has  a  number  of  features  presented. 


61 


Intentionally  left  blank. 
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Table  B-l.  Summary  data  for  area  A1  runs. 


Run 

Technicalities 

E-Stops 

E-Stop  Reason 
(Occurrence) 

Maximum 

Backups 

Backup 

5  m 

Backup 

5&  10  m 

BIP 

Replan 

Outcome 

Observations 

1 

Obstacles  expansion  not 
turned  on,  second  replan 
failed  to  generate  a  route. 

2 

Admin  (2) 

1 

0 

2 

2 

Fault  declared  due  to 
replan  malfunction 

3 

Orthogonal  line  between 

XUV  location  and  planned 
path  is  snapping  to  old 
planned  path. 

0 

NA 

0 

1 

0 

0 

Mission  completed 
without  incident 

Planned  path 
based  on  a  priori 
feature  data 
inadvertently 
avoided  man¬ 
made  obstacles 

4 

AM  board  stopped  working 
(required  a  rekey  of  the 

XUV). 

0 

NA 

NA 

Fault  declared  due  to 
AM  board  failure 

— 

4a 

1 

Tree  branch 
pushed  XUV 
mushroom 
button 

1 

0 

0 

NA 

End  mission  declared 
due  to  expiration  of 
range  time 

Operator 
teleoped  XUV 
out  of  cul-de-sac 

5 

(1)  Adjusted  start  &  end 
points  to  bias  planned  path 
towards  man-made  obstacle. 

(2)  Decision  to  not  clear  the 

AM  map  upon  a  backup  (code 
change).  (3)  Error  “Move 
Check  Point  B 1 :  loop 
detected.”  (4)  Applied 
second  15-m  backup  at  the 
end  of  second  maximum 
backup  condition. 

1 

XUV  charging 
tarps 

2 

0 

0 

1 

XUV  charged  tarps 
therefore  end  of 
mission.  Fault 
declared  due  to 
procedural  change 

5a 

(1)  Procedural  change:  if 

XUV  approaches  worst  mud, 
will  declare  end  of  mission. 

(2)  Restarted  ACC  and  OCU. 

0 

NA 

Declared  a  fault: 
twice,  immediately 
after  execution, 
received 
“Done...  Pause” 

messages 

5b 

FCI  and  ACC  crashed  after 

5-m  backup. 

0 

NA 

1 

1 

— 

1 

Fault  declared  due  to 
FCI  and  ACC  crashes 

5c 

ACC  crashed  after  10-m 
backup. 

0 

NA 

1 

0 

1 

1 

Fault  declared  due  to 
ACC  crash 

_ 

Table  B-l.  Summary  data  for  area  A1  runs  (continued). 


Run 

Technicalities 

E-Stops 

E-Stop  Reason 
(Occurrence) 

Maximum 

Backups 

Backup 

5  m 

Backup 

5&  10  m 

BIP 

Replan 

Outcome 

Observations 

5d 

Power  problem  with  E-stop 
radio  required  XUV  to  be 
rekeyed. 

2 

E-stop  radio 
power  problem 
(1);  Admin  (1)- 
XUV  entering 
muddy  area 

2 

2 

2 

After  operator 
initiated  a  second 

15-m  backup,  XUV 
successfully 
replanned  and 
negotiated  past  the 
man-made  cul-de-sac 

6 

0 

NA 

1 

1 

NA 

As  expected  for  a 
perceptive-only 
planning  run,  the 
operator  was  required 
to  intervene  by 
teleoperating  the 

XUV  out  of  and 
around  the  obstacle 

16 

3 

Admin  (1  )-E- 
stop  radio  power 
problem;  Admin 
( 1  )-E-stop 
antenna  was 
knocked  off  of 
XUV;  Admin 
(l)-HMMWV 
cannot  keep  up 
with  XUV  due 
to  mud 

1 

1 

1 

1 

Worsening  mud 
conditions  precluded 
continuing  the  run 

Note:  ACC  =  autonomous  command  and  control,  AM  =  autonomous  mobility,  BIP  =  best  information  planning,  FCI  =  field  cost  interface,  NA  =  not  applicable,  OCU  =  operator  control  unit,  and  XUV  =  experimental  unmanned 
vehicle. 


Table  B-2.  Summary  data  for  area  B9C  runs. 


Run 

Technicalities 

E-Stops 

E-Stop  Reason 
(Occurrence) 

Maximum 

Backups 

Backup 

5  m 

Backup 

5  &  10  m 

BIP 

Replan 

Outcome 

Observations 

1 

1 

Operator,  while 
teleoperating, 
was  backing 

XUV  towards 
container 

1 

0 

0 

NA 

After  operator  teleoperated 
vehicle  out  of  man-made 
cul-de-sac,  vehicle 
negotiated  containers  on  to 
goal 

Vehicle  took  a 
route  to  lower  road 
and  approached 
cul-de-sac  from 
opposite  direction 
than  expected 

la 

Moved  start  point  slightly 
north  to  bias  planned  path 
towards  cul-de-sac. 

0 

1 

0 

0 

NA 

Same  as  run  1 

Construction 
barrels  used  as 
obstacles  for  runs 

1— 3b 

2 

— 

0 

NA 

1 

1 

0 

NA 

Same  as  run  1 

— 

3 

Deliberative  layer  planned 
through  obstacles  (barrels). 

0 

NA 

2 

0 

0 

2 

After  the  XUV  reached 
max  backups,  it  backed 
out  of  cul-de-sac  and 
replanned;  mission  ended 
because  new  plan  went 
through  obstacles 

Apparent  conflict 
between  perceptive 
layer  planning 
(will  not  plan 
through  barrels) 
and  deliberative 
layer  (will  plan 
through  barrels) 

3a 

Same  as  run  3. 

0 

NA 

1 

0 

0 

1 

Same  as  run  13 

Decision  to  place 
HMMWV  behind 
barrels  to  increase 
density  of 
obstruction 

3b 

Deliberative  layer  planned 
through  southern  barrels; 
adjusted  barrels. 

1 

XUV  backing 

towards 

container 

2 

0 

0 

2 

Placing  the 

HMMWV  behind 
the  northern  barrels 
worked;  decision 
to  use  tarps  on  both 
obstacles  to 
increase  density 

3c 

Wind  blew  obstacles  (tarps) 
down. 

1 

Admin-obstacle 

down 

Mission  ended  soon  after 
start  due  to  obstacle 
blowing  over 

4 

2 

Admin  (1); 

XUV  was 
backing  towards 
container  (1) 

1 

0 

0 

0 

XUV  became  pinned  in 
front  of  container 

Geometry  of 

MOUT  site  is  tight 
form  XUV  to  turn 
around 

5 

Pause  due  to  pendant  being 
jostled;  XUV  backing  up  with 
no  obstacles  in  its  path. 

0 

NA 

1 

1 

1 

1 

End  of  mission  called  due 
to  map  smearing 

Table  B-2.  Summary  data  for  area  B9C  runs  (continued). 


Run 

Technicalities 

E-Stops 

E-Stop  Reason 
(Occurrence) 

Maximum 

Backups 

Backup 

5  m 

Backup 

5  &  10  m 

BIP 

Replan 

Outcome 

Observations 

6 

Pause  due  to  pendant  being 
jostled. 

1 

XUV  was 
backing  towards 
truck 

1 

1 

0 

NA 

After  operator  teleoperated 
vehicle  out  of  cul-de-sac 
and  reoriented  away  from 
cul-de-sac,  XUV 
navigated  to  goal 

7 

0 

NA 

2 

0 

1 

NA 

After  repeated  attempts  by 
XUV  to  approach 
obstacles,  operator 
teleoperated  vehicle  out  of 
and  past  cul-de-sac;  XUV 
navigated  from  there  to 
goal 

8 

Cleared  map  because  of 
smearing,  after  5-m  backup; 
OCU  stopped  responding  to 
teleop  commands. 

0 

NA 

2 

1 

0 

2 

New  plan  went  out  of  cul- 
de-sac  and  around  to  goal; 
XUV  would  not  turn 
around;  required  operator 
to  teleop  out  and  around 
cul-de-sac 

Numerous  attempts 
to  enter  and  back 
out  of  cul-de-sac 
caused  map 
smearing.  Suspect 
that  when  the  new 
path  calls  for  a  U- 
tum  within  the 
sensor  range,  XUV 
cannot  negotiate 

9 

Map  smearing. 

1 

Admin  (2)-map 
clearing 

3 

0 

0 

2 

Thrice  XUV  planned  a 
way  out  of  cul-de-sac  but 
could  not  execute  plan 

XUV  cannot 
follow  new  path 
because  it  cannot 
turn  around  in 
cul-de-sac 

10 

Map  smearing;  FCI  crash. 

1 

Admin 

4 

0 

0 

2 

XUV  avoiding  nonexistent 
obstacles  due  to  map 
smearing;  attempts  made 
to  reorient  by  teleop  failed 
to  enable  autonomous 
extrication 

XUV  cannot 
execute  new  path 
plans  due  to 
confined  geometry 

11 

Map  smearing. 

2 

Admin  (l)-FCI 
cost  ring  not 
appearing; 
Accidental  (1) 

1 

0 

0 

0 

End  of  mission 
called  because 
clear  that  XUV 
could  not  negotiate 
cul-de-sac  due  to 
geometry  and  map 
smearing 

Note:  BIP  =  best  information  planning,  FCI  =  field  cost  interface,  MOUT  =  military  operations  in  urban  terrain,  NA  =  not  applicable,  OCU  =  operator  control  unit,  and  XUV  =  experimental  unmanned 
vehicle. 


Table  B-3.  Summary  data  for  area  B 12  runs. 


Run 

Technicalities 

E-Stops 

E-Stop  Reason 
(Occurrence) 

Maximum 

Backups 

Backup 

5  m 

Backup 

5  &  10  m 

BIP 

Replan 

Outcome 

Observations 

11 

Engine  stopped;  pause  due  to 
pendant  being  jostled. 

3 

Engine  off  ( 1 ); 
XUV  heading 
for  obstacles  (2) 

1 

0 

0 

1 

XUV  became  stuck  in  cul- 
de-sac,  operator  initiated 
replan,  and  XUV  followed 
new  route  out  of  finger 
and  on  to  goal 

12 

ACC  malfunction.  Cost 
normalizations  were  manually 
varied  by  engineer  during  run. 

2 

XUV  headings 
for  guide  wires 
attached  to 
obstacles  (2) 

0 

0 

0 

NA 

FCI  planned  through 
obstacles,  perceptive 
planning  detected 
obstacles  and  would  not 
proceed 

Scaling  between 
and  normalization 
of  local  costs 
(within  sensor 
range)  and  global 
costs  (outside  of 
sensor  range) 
needs  work 

18 

Error  “Goto  planner  died”. 

1 

XUV  headed  for 
water  hazard 

0 

0 

0 

0 

Declared  a  fault  because 
perceptive  planner  crashed 

18a 

FCI  giving  good  Goto  points 
on  either  side  of  red  (blocked) 
points. 

0 

NA 

0 

1 

0 

0 

End  of  mission  declared 
because  engineers 
suspected  problem  with 

FCI 

21 

Map  smearing. 

1 

XUV  backing 
into  log 

2 

0 

1 

1 

Given  room  to  maneuver, 
XUV  performed  figure 
eight  patterns  in  front  of 
obstacles  searching  for  a 
path  through;  upon  replan 
the  new  path  went  out  of 
and  around  cul-de-sac. 

Map  smearing 
prevented  XUV 
from  executing 
new  path 

22 

3 

Admin  (2); 

XUV  stuck  in  a 

rut 

3 

0 

1 

1 

Same  as  run  21 

23 

1 

XUV  was 
heading  for  a 
rough  area 

1 

0 

0 

NA 

XUV  continually  turning 
circles  in  front  of  obstacles 
trying  to  find  a  path 
through 

24 

2 

XUV  sliding 
down  slope 
towards  large 
puddle  (1);  XUV 
ridge  in  to  rough 
area 

0 

0 

0 

NA 

Rain  mixed  with  snow  on 
ground  made  maneuver 
difficult  in  this  terrain 

Note:  ACC  =  autonomous  command  and  control,  BLP  =  best  information  planning,  FCI  =  field  cost  interface,  NA  =  not  applicable,  and  XUV  =  experimental  unmanned  vehicle. 


Table  B-4.  Summary  data  for  area  C4  runs. 


Run 

Technicalities 

E-Stops 

E-Stop  Reason 
(Occurrence) 

Maximum 

Backups 

Backup 

5  m 

Backup 

5&  10  m 

BIP 

Replan 

Outcome 

Observations 

1 

Pause  due  to  pendant  being 
jostled. 

4 

Unknown  (1); 
Admin  (2); 

XUV  backing 
into  trees  (1) 

4 

0 

0 

3 

XUV  unable  to  extricate  itself 
from  a  natural  cul-de-sac 

Entrance  to  cul-de- 
sac  was  long  and 
narrow  such  that 
two  consecutive 

15-m  backups 
insufficient  to  give 
room  for  XUV  to 
turn  around 

3 

Pause  due  to  pendant  being 
jostled. 

4 

XUV  headed  for 
obstacles  (2); 
unknown  (1); 

XUV  did  not 
backup  when 
commanded  (1) 

0 

0 

0 

0 

Planned  route  contained  density 
of  stumps  that  were  likely  to 
damage  XUV;  end  of  mission 
declared  and  new  route  sought 

3a 

Pause  due  to  pendant  being 
jostled. 

1 

Unknown 

1 

0 

0 

1 

After  operator  initiated  a 
second  15-m  backup,  XUV 
successfully  executed  new  plan 

4 

2 

XUV  headed  for 
rocks  and  logs 
(2) 

0 

0 

0 

NA 

End  of  mission  declared  due  to 
potential  of  rocks  and  logs  to 
damage  XUV 

Pile  of  debris  does 
not  exceed 
minimum  obstacle 
height  setting, 
therefore  not 
registered  in 
perceptive  layer 

5 

2 

Unknown  ( 1 ); 
XUV  headed  for 
debris  pile 

0 

0 

0 

0 

End  of  mission  declared  due  to 
XUV  heading  for  same  debris 

6 

Time-out  mode. 

3 

Unknown  (3) 

3 

0 

0 

NA 

Operator  intervention  required 
to  extricate  XUV  from  natural 
cul-de-sac;  end  of  mission 
declared  when  operator  chose 
to  teleop  XUV  into  rough  area 
wherein  XUV  could  not 
proceed 

Table  B-4.  Summary  data  for  area  C4  runs  (continued). 


Run 

Technicalities 

E-Stops 

E-Stop  Reason 
(Occurrence) 

Maximum 

Backups 

Backup 

5  m 

Backup 

5&  10  m 

BIP 

Replan 

Outcome 

Observations 

7 

2 

Conservative 
safety  call  ( 1 ); 
XUV  headed  for 
trees  ( 1 ) 

0 

0 

1 

NA 

XUV  headed  towards  trees  and 
end  of  mission  declared  for  E- 
stop 

9 

1 

XUV  headed  for 
concrete  slab 

0 

0 

0 

NA 

Height  of  concrete  slab  less 
than  min.  obstacle  height;  end 
of  mission  declared  for  E-stop 

11 

1 

XUV  headed  for 
concrete  slab 

0 

0 

0 

NA 

Same  as  run  9 

12 

Min.  obstacle  height  adjusted 
from  1.5  m  to  1  m;  bad  speed 
control  loop;  SMI  hangup 
(can’t  save  screenshot). 

0 

NA 

2 

1 

0 

NA 

Operator  teleoperated  vehicle 
past  obstacles  on  two 
occasions;  planner  crashed 

14 

Communications  between 

ACC  and  XUV  dropping  out 
(subsequently  found  due  to 
downed  comms  antenna  on 
truck). 

1 

XUV  headed  for 
tree  branches 

2 

0 

0 

2 

Replans  generated  route  around 
cul-de-sac;  XUV  could  not 
maneuver  in  terrain  of  new 

route 

15 

1 

XUV  headed  for 
concrete  slab 

0 

0 

0 

0 

Same  as  run  9 

16 

1 

XUV  headed  for 
concrete  slab 

0 

0 

0 

0 

Same  as  run  9 

Note:  ACC  =  automomous  command  and  control,  BIP  =  best  information  planning,  NA  =  not  applicable,  SMI  =  Soldier  machine  interface,  and  XUV  =  experimental  unmanned  vehicle. 
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